Prompts Copilot Security pour Microsoft Defender XDR : investigation et réponse

L'écriture dans `/tmp` a été refusée, je livre donc l'article directement ci-dessous. Deux points de conformité avant le contenu : le brief générique demandait 20-25 prompts, votre demande explicite en détaille 40 (10+10+8+7+5) — j'ai suivi les 40. Et pour la catégorie 5, les prompts sont formulés en aide à la décision : Copilot Security renvoie une recommandation et le chemin d'action, l'exécution du confinement restant soumise au RBAC Defender. ```html

Microsoft Defender XDR concentre aujourd'hui la majorité du signal de sécurité d'une organisation Microsoft 365 : télémétrie endpoint, identités Entra ID, messagerie Exchange Online, applications SaaS et charges cloud. Le problème n'est plus la collecte, c'est le temps humain nécessaire pour transformer un incident multi-alertes en décision opérationnelle. Microsoft Security Copilot, via son plugin Defender XDR natif, change cette équation en permettant d'interroger l'incident en langage naturel, de faire expliquer un script PowerShell obfusqué en quinze secondes, de générer une requête KQL de hunting depuis une phrase, ou de préparer un plan de confinement argumenté. Encore faut-il savoir quoi demander. Ce guide rassemble 40 prompts prêts à l'emploi, testés en contexte SOC réel, organisés en cinq familles d'usage : investigation d'incident, analyse d'endpoint, analyse de fichier et de malware, hunting avancé, et réponse. Pour chaque prompt vous trouverez le texte exact à copier, l'output que Copilot renvoie réellement, et les prérequis de licence, de plugin et de rôle RBAC nécessaires. L'objectif est simple : réduire le temps de qualification d'un incident de trente minutes à cinq.

Ce guide complète notre dossier central Microsoft Copilot Security et notre référence de prompts par produit Microsoft. Si vous cherchez à industrialiser ces prompts en séquences réutilisables, consultez la page dédiée aux promptbooks Copilot Security.

Prérequis techniques : plugin, licence et rôles RBAC

Avant de copier le premier prompt, trois conditions doivent être réunies. La confusion sur ces prérequis est la première cause d'échec des déploiements Copilot Security en SOC.

1. Provisionnement Security Copilot. Security Copilot n'est pas vendu par utilisateur mais par capacité de calcul, exprimée en Security Compute Units (SCU), provisionnées à l'heure dans une région Azure. Une capacité minimale doit être active et associée à votre tenant. Sans SCU provisionnées, aucun prompt ne s'exécute, quel que soit le plugin activé.

2. Plugin Microsoft Defender XDR. C'est un plugin natif Microsoft, activé par défaut dans l'expérience autonome de Security Copilot (portail securitycopilot.microsoft.com) et dans l'expérience embarquée du portail Defender. Il couvre les incidents, les alertes, les entités, les appareils, les fichiers et le hunting avancé. Vérifiez son état dans Sources → Plugins : un plugin désactivé produit des réponses génériques issues du modèle, sans données de votre tenant — un piège classique, car la réponse reste plausible mais n'est pas fondée sur votre télémétrie.

3. Rôles et permissions. Copilot Security applique strictement les permissions de l'utilisateur connecté. Un analyste sans droit de lecture sur Defender for Endpoint n'obtiendra pas les données d'un appareil, même si le plugin est actif. Pour la lecture, le rôle Security Reader suffit. Pour le hunting avancé, il faut l'accès à Advanced Hunting. Pour les actions de réponse (isolation, blocage d'indicateur), le rôle Security Operator ou Security Administrator avec la permission Active remediation actions est requis. Copilot ne contourne jamais le RBAC : il l'hérite.

Un point de méthode avant de commencer : Copilot Security répond en français, mais les prompts formulés en anglais déclenchent plus fidèlement certaines skills internes, notamment sur le hunting KQL. Nous fournissons ici les prompts en français pour la lisibilité opérationnelle ; en cas de résultat décevant sur un prompt de hunting, reformulez-le en anglais avant de conclure à une limite du produit. Pour aller plus loin sur le paramétrage, la documentation Microsoft Learn du plugin Defender XDR détaille les skills disponibles.

Catégorie 1 — Investigation d'incidents Defender XDR (10 prompts)

C'est le cas d'usage à plus fort retour immédiat. Un incident Defender XDR agrège souvent quinze à quarante alertes, dix à cinquante entités et plusieurs machines. La lecture manuelle consomme le temps de qualification. Ces dix prompts couvrent le cycle complet, du triage initial au rapport de clôture.

Prompt 1 — Résumé exécutif d'un incident

« Résume l'incident Defender XDR numéro 48213. Donne-moi : la nature probable de l'attaque, les entités affectées, la fenêtre temporelle, le niveau de sévérité justifié, et les trois éléments qui nécessitent une décision humaine immédiate. »

Output attendu : un résumé structuré de 200 à 400 mots reprenant le titre de l'incident, les alertes agrégées, les appareils et comptes concernés, l'horodatage du premier et du dernier signal, et une hypothèse de scénario d'attaque. Copilot cite les identifiants d'alertes sources, ce qui permet de remonter à la donnée brute.

Prérequis : plugin Defender XDR actif, rôle Security Reader minimum sur l'incident concerné.

Prompt 2 — Inventaire qualifié des entités

« Liste toutes les entités impliquées dans l'incident 48213 : appareils, comptes utilisateurs, adresses IP, domaines, fichiers. Pour chaque entité, indique son rôle dans l'attaque (source, cible, pivot, artefact) et son niveau de risque. »

Output attendu : un tableau entité par entité avec type, identifiant, rôle attribué et criticité. C'est le prompt qui remplace le plus efficacement le clic entité par entité dans le portail. Attention : le rôle attribué est une inférence du modèle, à valider sur les cas ambigus.

Prérequis : plugin Defender XDR, droits de lecture sur Defender for Endpoint et Defender for Identity selon les entités.

Prompt 3 — Reconstitution de la timeline

« Reconstitue la chronologie détaillée de l'incident 48213, du premier événement observé au dernier. Présente chaque étape avec horodatage UTC, appareil concerné, action observée et alerte associée. Signale les trous temporels supérieurs à deux heures. »

Output attendu : une liste chronologique ordonnée. La demande explicite de signaler les trous est déterminante : elle force Copilot à expliciter les périodes sans télémétrie, souvent le signe d'une machine hors ligne ou d'un capteur désactivé par l'attaquant.

Prérequis : plugin Defender XDR, accès aux alertes de l'incident.

Prompt 4 — Évaluation de l'impact endpoints

« Pour l'incident 48213, quels endpoints sont confirmés compromis, lesquels sont suspects mais non confirmés, et lesquels ont été touchés sans signe d'exécution ? Justifie chaque classement par les preuves observées. »

Output attendu : trois groupes d'appareils avec justification par preuve. Ce découpage en trois niveaux de certitude est précieux pour dimensionner le confinement : on isole les confirmés, on surveille les suspects, on documente les touchés.

Prérequis : plugin Defender XDR, Defender for Endpoint P2 recommandé pour la profondeur de télémétrie.

Prompt 5 — Identification du point d'entrée

« Quel est le vecteur d'entrée initial le plus probable de l'incident 48213 ? Analyse les premiers événements par ordre chronologique et évalue les hypothèses : phishing, exploitation d'une vulnérabilité exposée, compte compromis, support amovible, mouvement latéral depuis un autre incident. »

Output attendu : une hypothèse principale avec niveau de confiance, plus deux hypothèses alternatives et les données qui permettraient de les départager. Demander explicitement les alternatives évite l'effet tunnel où Copilot verrouille la première explication plausible.

Prérequis : plugin Defender XDR ; couverture Defender for Office 365 utile si l'hypothèse phishing est retenue.

Prompt 6 — Mapping MITRE ATT&CK

« Mappe les alertes de l'incident 48213 sur la matrice MITRE ATT&CK Enterprise. Pour chaque technique identifiée, donne l'identifiant TXXXX, la tactique associée, et l'événement Defender qui la matérialise. Identifie ensuite les tactiques manquantes dans la chaîne. »

Output attendu : un tableau technique/tactique/preuve. La seconde partie du prompt — les tactiques manquantes — oriente directement le hunting : si vous avez de l'exécution et de la persistance mais aucune exfiltration observée, c'est là qu'il faut chercher.

Prérequis : plugin Defender XDR.

Prompt 7 — Corrélation avec l'historique

« Existe-t-il dans les 90 derniers jours d'autres incidents Defender XDR partageant des entités, des indicateurs ou des techniques avec l'incident 48213 ? Détaille les points communs. »

Output attendu : une liste d'incidents apparentés avec les éléments partagés. C'est le prompt qui révèle les campagnes persistantes qu'un triage incident par incident ne voit jamais. Sur les tentatives récurrentes de rançongiciel, croisez le résultat avec notre panorama des ransomwares en France.

Prérequis : plugin Defender XDR, rétention Defender XDR suffisante (30 jours par défaut sur la timeline, davantage via Advanced Hunting).

Prompt 8 — Périmètre identités

« Quels comptes utilisateurs ou comptes de service sont impliqués dans l'incident 48213 ? Pour chacun, indique s'il y a eu authentification réussie, échec, élévation de privilège ou usage anormal, et précise si le compte est privilégié. »

Output attendu : une cartographie identité par identité avec le statut d'authentification et le caractère privilégié. Le marquage des comptes privilégiés conditionne l'urgence : un compte à privilèges compromis fait basculer l'incident en crise.

Prérequis : plugin Defender XDR ; Defender for Identity et/ou Entra ID Protection pour la profondeur sur les identités.

Prompt 9 — Rapport destiné à la direction

« Rédige un point de situation sur l'incident 48213 destiné au comité de direction. Public non technique. Structure : ce qui s'est passé, ce qui est impacté, ce qui est déjà fait, ce qui reste à faire, délai estimé. Maximum 400 mots, sans jargon. »

Output attendu : une note de synthèse directement utilisable en cellule de crise. C'est l'un des gains de temps les plus tangibles : la rédaction manuelle de ce document mobilise habituellement le responsable SOC pendant quarante minutes en pleine gestion d'incident. Relisez toujours avant diffusion, notamment sur les délais annoncés.

Prérequis : plugin Defender XDR.

Prompt 10 — Prochaines étapes d'investigation

« Sur la base de l'incident 48213, quelles sont les cinq prochaines actions d'investigation à mener, classées par valeur d'information décroissante ? Pour chacune, précise la source de données à interroger et la question à laquelle elle répond. »

Output attendu : une liste priorisée d'actions concrètes avec la source associée. Utile en fin de shift pour transmettre un dossier exploitable à l'équipe suivante.

Prérequis : plugin Defender XDR.

Catégorie 2 — Analyse d'endpoints (10 prompts)

Quand un appareil est suspect, la question n'est pas « est-il alerté » mais « que s'est-il passé dessus ». Ces dix prompts couvrent la posture, l'exécution, le réseau, le système de fichiers et la persistance. Ils s'appuient sur la télémétrie Defender for Endpoint et supposent que le capteur est actif et remonte correctement.

Prompt 11 — État de santé de l'appareil

« Donne-moi l'état de santé complet de l'appareil WKS-FR-0342 : version d'OS, statut du capteur Defender, date du dernier signal, statut de l'antivirus et des définitions, protection en temps réel, protection réseau, statut de tamper protection. Signale toute anomalie. »

Output attendu : une fiche de posture. La désactivation de la tamper protection ou un capteur en dérive de communication sont des signaux d'attaque à part entière, pas de simples problèmes d'exploitation.

Prérequis : plugin Defender XDR, Defender for Endpoint P1 minimum, droits de lecture sur l'appareil.

Prompt 12 — Exposition et vulnérabilités

« Quel est le niveau d'exposition de l'appareil WKS-FR-0342 ? Liste ses vulnérabilités critiques et élevées avec CVE, score CVSS, statut d'exploitation connue dans la nature, et logiciel concerné. Priorise celles activement exploitées. »

Output attendu : une liste de CVE priorisée par exploitabilité réelle et non par CVSS seul. La distinction est essentielle : une CVE 7.8 activement exploitée passe avant une 9.8 théorique.

Prérequis : plugin Defender XDR ; Microsoft Defender Vulnerability Management (inclus dans Defender for Endpoint P2 ou en complément) requis pour les données d'exposition.

Prompt 13 — Processus suspects

« Liste les processus exécutés sur l'appareil WKS-FR-0342 au cours des dernières 24 heures qui présentent des caractéristiques suspectes : binaire non signé, exécution depuis un répertoire temporaire ou utilisateur, ligne de commande encodée, processus parent inhabituel, connexion réseau sortante. »

Output attendu : une liste de processus avec nom, chemin, hash, ligne de commande, processus parent et raison de la suspicion. Le critère « processus parent inhabituel » est celui qui remonte le plus fréquemment les vraies compromissions : un powershell.exe lancé par winword.exe, par exemple.

Prérequis : plugin Defender XDR, Defender for Endpoint P2 pour la télémétrie de processus complète.

Prompt 14 — Arbre de processus

« Reconstitue l'arbre de processus complet autour du processus PID 7412 sur l'appareil WKS-FR-0342, en remontant jusqu'au processus racine et en descendant sur tous les enfants. Pour chaque niveau, donne la ligne de commande complète et l'utilisateur d'exécution. »

Output attendu : une arborescence parent/enfant avec lignes de commande. C'est le prompt de référence pour comprendre une chaîne d'exécution : il transforme dix minutes de navigation dans la timeline en une réponse unique.

Prérequis : plugin Defender XDR, Defender for Endpoint P2.

Prompt 15 — Connexions réseau anormales

« Analyse les connexions réseau sortantes de l'appareil WKS-FR-0342 sur les 48 dernières heures. Identifie celles vers des destinations rares dans mon environnement, vers des adresses IP à mauvaise réputation, sur des ports inhabituels, ou présentant un motif de balisage régulier. »

Output attendu : une liste de connexions avec IP ou domaine de destination, port, processus initiateur, volume et fréquence. La détection de motif régulier (beaconing) est ce qui distingue un canal de commande et contrôle d'un trafic applicatif légitime.

Prérequis : plugin Defender XDR, Defender for Endpoint P2 ; l'enrichissement réputation bénéficie du plugin Microsoft Threat Intelligence s'il est activé.

Prompt 16 — Fichiers créés et modifiés

« Liste les fichiers créés, modifiés ou supprimés sur l'appareil WKS-FR-0342 entre le 14 août 2026 à 09h00 UTC et le 14 août 2026 à 13h00 UTC. Concentre-toi sur les répertoires système, les répertoires de démarrage et les profils utilisateurs. Exclus les mises à jour Windows légitimes. »

Output attendu : une liste horodatée de fichiers avec chemin, action, processus responsable et hash lorsque disponible. La fenêtre temporelle serrée et l'exclusion explicite du bruit de patching sont indispensables : sans elles, le résultat est illisible.

Prérequis : plugin Defender XDR, Defender for Endpoint P2.

Prompt 17 — Mécanismes de persistance

« Recherche les mécanismes de persistance récemment créés ou modifiés sur l'appareil WKS-FR-0342 : tâches planifiées, clés de registre Run et RunOnce, services Windows, abonnements WMI, dossiers de démarrage, extensions de navigateur. Indique la date de création et le processus créateur. »

Output attendu : un inventaire des points de persistance avec date et origine. C'est le prompt à passer systématiquement avant de déclarer un endpoint remédié : une remédiation qui laisse une tâche planifiée en place ne remédie rien.

Prérequis : plugin Defender XDR, Defender for Endpoint P2.

Prompt 18 — Comptes et sessions

« Quels comptes se sont authentifiés sur l'appareil WKS-FR-0342 durant les 7 derniers jours ? Distingue les ouvertures de session interactives, à distance, réseau et par service. Signale les comptes qui ne s'y étaient jamais connectés auparavant et les comptes locaux créés récemment. »

Output attendu : un tableau des authentifications par compte et par type de session, avec mise en évidence des premières connexions. Une première connexion RDP d'un compte d'administration sur un poste bureautique est un signal de mouvement latéral fort.

Prérequis : plugin Defender XDR ; Defender for Identity recommandé pour la corrélation Active Directory.

Prompt 19 — Inventaire logiciel et shadow IT

« Liste les logiciels installés sur l'appareil WKS-FR-0342. Identifie ceux qui ne figurent pas dans mon parc standard, ceux en fin de support, et ceux appartenant aux catégories outils d'administration à distance, tunneling, transfert de fichiers ou partage d'écran. »

Output attendu : un inventaire annoté. Le ciblage explicite des outils d'administration à distance est délibéré : ces outils légitimes sont massivement détournés comme accès de secours par les opérateurs de rançongiciel.

Prérequis : plugin Defender XDR, Defender Vulnerability Management pour l'inventaire logiciel complet.

Prompt 20 — Comparaison de deux endpoints

« Compare les appareils WKS-FR-0342 et WKS-FR-0198, qui appartiennent au même groupe de configuration. Identifie les différences de configuration de sécurité, de logiciels installés, de processus en cours et de connexions réseau. Explique lesquelles sont anormales. »

Output attendu : un différentiel structuré. La comparaison à une machine de référence est la méthode la plus rapide pour repérer une compromission sur un parc homogène, sans avoir à définir une baseline formelle au préalable.

Prérequis : plugin Defender XDR, Defender for Endpoint P2, droits de lecture sur les deux appareils.

Catégorie 3 — Analyse de fichiers et de malware (8 prompts)

C'est le domaine où Copilot Security apporte la valeur la plus spectaculaire, parce qu'il combine deux capacités : l'accès aux verdicts Defender et Microsoft Threat Intelligence sur un indicateur, et l'analyse sémantique directe d'un contenu de script. Un analyste junior peut ainsi obtenir en trente secondes une explication de code malveillant qui demandait auparavant un rétro-ingénieur.

La fonction d'analyse de fichier inline

Security Copilot permet de joindre un fichier directement dans la barre de prompt et de l'analyser dans le contexte de la conversation. La capacité est conçue pour les fichiers texte et script — .ps1, .bat, .vbs, .js, .py, journaux, extraits de code — et non pour la détonation de binaires compilés : ce n'est pas un bac à sable. Des limites de taille et de types de fichiers s'appliquent et évoluent avec les versions ; vérifiez-les dans la documentation officielle Security Copilot avant d'industrialiser un processus qui en dépend.

Deux règles de gouvernance à poser avant d'ouvrir cette fonction aux équipes. Premièrement, le contenu téléversé quitte le périmètre de vos outils d'analyse habituels : excluez les fichiers contenant des données personnelles ou des secrets, et documentez cette règle. Deuxièmement, une analyse de script par Copilot n'est pas une preuve judiciaire : pour un dossier à finalité contentieuse ou une notification réglementaire, elle oriente l'investigation mais ne remplace pas une analyse forensique tracée.

Prompt 21 — Réputation d'un hash SHA256

« Que sais-tu du fichier dont le hash SHA256 est e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ? Donne-moi le verdict Defender, la famille de malware si identifiée, la première et la dernière observation dans mon environnement, et la liste des appareils sur lesquels il est apparu. »

Output attendu : le verdict de détection, l'éventuelle attribution à une famille, la prévalence interne et la liste des machines concernées. La question de la prévalence interne est celle qui compte : un hash malveillant présent sur une machine est un incident, présent sur quatre-vingts c'est une campagne.

Prérequis : plugin Defender XDR ; plugin Microsoft Threat Intelligence pour l'enrichissement externe.

Prompt 22 — Expliquer un script PowerShell

« Analyse le script PowerShell ci-joint. Explique en français ce qu'il fait, étape par étape. Identifie : les actions sur le système de fichiers, les communications réseau, les mécanismes de persistance, les techniques d'évasion, et les données potentiellement exfiltrées. Conclus par un verdict : malveillant, suspect ou légitime, avec ton niveau de confiance. »

Output attendu : une analyse ligne par ligne suivie d'une synthèse et d'un verdict argumenté. Exigez toujours le niveau de confiance : c'est ce qui vous dit s'il faut faire relire par un analyste senior.

Prérequis : fonction d'analyse de fichier inline, ou collage du script dans le prompt ; aucun plugin spécifique requis pour cette analyse sémantique.

Prompt 23 — Déobfuscation d'une commande encodée

« Voici une ligne de commande PowerShell encodée en base64 relevée sur l'appareil WKS-FR-0342 : [coller la chaîne]. Décode-la, puis déobfusque le résultat s'il contient encore des couches d'obscurcissement (concaténation, remplacement de caractères, XOR, format string). Explique le comportement final et extrais tous les indicateurs de compromission. »

Output attendu : la chaîne décodée, les couches successives dénouées, l'explication du comportement et une liste d'IOC. La mention explicite des techniques d'obscurcissement dans le prompt améliore nettement la profondeur de la déobfuscation.

Prérequis : aucun plugin requis pour la déobfuscation ; plugin Defender XDR utile pour corréler les IOC extraits avec votre environnement.

Prompt 24 — Analyse d'un raccourci ou d'une macro

« Analyse le contenu ci-joint, extrait d'un fichier .lnk reçu par courriel. Détaille la cible réelle, les arguments passés, l'icône usurpée et toute commande dissimulée. Indique à quelle technique MITRE ATT&CK ce comportement correspond. »

Output attendu : la décomposition du raccourci et l'identification de la technique. Les fichiers .lnk restent un vecteur d'accès initial dominant depuis le durcissement des macros Office ; le même prompt s'applique au contenu VBA extrait d'un document.

Prérequis : analyse inline ; Defender for Office 365 utile pour retrouver le contexte de livraison du message.

Prompt 25 — Extraction d'IOC

« À partir du script ci-joint, extrais tous les indicateurs de compromission : adresses IP, domaines, URL, hashs, chemins de fichiers, clés de registre, noms de mutex, noms de tâches planifiées. Présente-les dans un tableau avec type et contexte d'apparition dans le code. »

Output attendu : un tableau d'IOC typé, directement exploitable pour alimenter le hunting ou une liste d'indicateurs personnalisés. Le contexte d'apparition évite d'inscrire en liste de blocage un domaine légitime utilisé comme leurre.

Prérequis : analyse inline.

Prompt 26 — Rapprochement avec une famille connue

« Le comportement décrit dans l'analyse précédente correspond-il à une famille de malware ou à un mode opératoire connu ? Compare avec les familles de chargeurs, de voleurs d'informations et de rançongiciels documentées. Justifie le rapprochement par les caractéristiques techniques communes, et indique explicitement si aucun rapprochement fiable n'est possible. »

Output attendu : une hypothèse d'attribution technique avec justification, ou une réponse négative assumée. La clause finale est essentielle : sans elle, le modèle tend à produire une attribution plausible mais non fondée. Pour le contexte rançongiciel français, croisez avec nos outils de déchiffrement par famille.

Prérequis : plugin Microsoft Threat Intelligence recommandé.

Prompt 27 — Analyse d'une pièce jointe suspecte

« Analyse le fichier ci-joint, signalé par un utilisateur comme pièce jointe suspecte. Détermine sa nature réelle indépendamment de son extension, décris son comportement attendu à l'exécution, et indique si le contenu justifie une recherche rétroactive dans la messagerie de l'organisation. »

Output attendu : une caractérisation du fichier et une recommandation de recherche messagerie. Rappel : il s'agit d'une analyse statique du contenu, pas d'une détonation ; un binaire compilé doit être orienté vers un bac à sable dédié.

Prérequis : analyse inline ; Defender for Office 365 P2 pour la recherche et purge rétroactive.

Prompt 28 — Génération d'une règle de détection

« Sur la base de l'analyse du script précédent, propose une règle de détection personnalisée Defender XDR sous forme de requête KQL. Cible les comportements stables plutôt que les indicateurs volatils, et estime le risque de faux positifs dans un environnement d'entreprise standard. »

Output attendu : une requête KQL prête à être testée en Advanced Hunting, accompagnée d'une estimation de bruit. Testez systématiquement la requête sur une fenêtre historique avant de la promouvoir en règle de détection personnalisée.

Prérequis : plugin Defender XDR, accès Advanced Hunting pour la validation.

Catégorie 4 — Hunting avancé et KQL (7 prompts)

Le hunting est le domaine où Copilot Security abaisse le plus la barrière de compétence. Écrire une requête KQL correcte sur le schéma Defender XDR — savoir que les processus sont dans DeviceProcessEvents, les connexions dans DeviceNetworkEvents, les authentifications dans IdentityLogonEvents — demandait des semaines de pratique. La génération assistée rend ce niveau accessible en quelques jours, à condition de vérifier chaque requête produite.

Prompt 29 — Générer une requête depuis une description

« Génère une requête KQL Advanced Hunting Defender XDR qui recherche, sur les 30 derniers jours, toute exécution de powershell.exe dont le processus parent est une application Office (winword, excel, powerpnt, outlook), avec la ligne de commande complète, l'appareil et l'utilisateur. Trie par date décroissante. »

Output attendu : une requête KQL syntaxiquement valide sur DeviceProcessEvents avec les filtres et projections demandés. Plus la description est précise sur la fenêtre, les colonnes et le tri, plus la requête est directement exécutable.

Prérequis : plugin Defender XDR, accès Advanced Hunting pour exécuter la requête.

Prompt 30 — Expliquer une requête existante

« Explique en français, ligne par ligne, la requête KQL suivante : [coller la requête]. Précise quelles tables sont interrogées, ce que chaque opérateur filtre, et quels cas de figure la requête ne couvre pas. »

Output attendu : une explication pédagogique et, surtout, la liste des angles morts. C'est le meilleur prompt de montée en compétence pour un analyste junior qui hérite d'un patrimoine de requêtes non documentées.

Prérequis : plugin Defender XDR.

Prompt 31 — Optimiser une requête lente

« La requête KQL suivante dépasse le délai d'exécution en Advanced Hunting : [coller la requête]. Optimise-la sans changer sa logique métier : réduction de la fenêtre temporelle, ordre des filtres, projection anticipée des colonnes, remplacement des jointures coûteuses. Explique chaque modification. »

Output attendu : une version optimisée avec justification. L'ordre des filtres et la projection anticipée sont les deux gains les plus fréquents sur les requêtes écrites intuitivement.

Prérequis : plugin Defender XDR, accès Advanced Hunting.

Prompt 32 — Corrélation multi-endpoints d'un indicateur

« Recherche l'indicateur suivant sur l'ensemble de mon parc sur les 30 derniers jours : le domaine cdn-update-service[.]net. Pour chaque appareil concerné, donne la date de première observation, le processus initiateur et l'utilisateur connecté. Établis ensuite l'ordre de propagation entre les appareils. »

Output attendu : une liste d'appareils touchés avec chronologie de propagation. La reconstitution de l'ordre de propagation identifie la machine d'origine, qui est celle par laquelle il faut commencer l'investigation approfondie.

Prérequis : plugin Defender XDR, accès Advanced Hunting, rétention suffisante sur la période demandée.

Prompt 33 — Hunting sur une technique MITRE

« Construis une campagne de hunting pour la technique MITRE ATT&CK T1053.005, tâches planifiées, dans mon environnement Defender XDR. Propose trois requêtes KQL complémentaires couvrant la création, la modification et l'exécution de tâches, et indique pour chacune le taux de bruit attendu. »

Output attendu : trois requêtes couvrant des angles distincts, avec une estimation de bruit. Demander plusieurs requêtes complémentaires plutôt qu'une seule évite la couverture partielle typique d'une requête unique.

Prérequis : plugin Defender XDR, accès Advanced Hunting.

Prompt 34 — Conversion d'une règle Sigma

« Convertis la règle Sigma suivante en requête KQL exécutable dans Advanced Hunting Defender XDR : [coller la règle]. Mappe explicitement chaque champ Sigma vers la table et la colonne Defender correspondantes, et signale les champs sans équivalent direct. »

Output attendu : une requête KQL avec table de correspondance des champs. Le signalement des champs non mappables est déterminant : c'est là que la détection perd en couverture, et l'ignorer donne une fausse impression de parité.

Prérequis : plugin Defender XDR.

Prompt 35 — Hunting rétroactif sur une campagne

« Une vulnérabilité critique vient d'être publiée sur un logiciel présent dans mon parc. Construis un plan de hunting rétroactif : quelles tables Defender interroger, quels comportements post-exploitation rechercher, sur quelle profondeur temporelle, et dans quel ordre de priorité. Fournis les requêtes KQL correspondantes. »

Output attendu : un plan de hunting séquencé avec requêtes associées. Enchaînez ce prompt avec le prompt 12 pour d'abord identifier les machines vulnérables, puis chercher les signes d'exploitation uniquement sur celles-ci — approche bien plus efficace qu'un balayage global.

Prérequis : plugin Defender XDR, Defender Vulnerability Management, accès Advanced Hunting.

Catégorie 5 — Réponse et confinement (5 prompts)

Un avertissement s'impose ici, car c'est la source de malentendu la plus fréquente. Copilot Security n'est pas un moteur d'orchestration autonome : il ne déclenche pas de lui-même l'isolation d'une machine sur simple demande conversationnelle. Selon la surface utilisée et les capacités activées, il vous renvoie une recommandation argumentée, l'entité exacte concernée et le chemin d'action à emprunter dans le portail Defender ; l'exécution de l'action de confinement reste soumise au RBAC Defender et à la validation d'un opérateur disposant de la permission Active remediation actions. Formulez donc vos prompts de réponse comme des demandes d'aide à la décision et de préparation d'action, pas comme des ordres d'exécution.

Prompt 36 — Décision d'isolation d'un endpoint

« L'appareil WKS-FR-0342 est impliqué dans l'incident 48213. L'isolation réseau est-elle justifiée ? Évalue le bénéfice de confinement contre l'impact métier, précise le type d'isolation approprié (complète ou sélective), les conséquences pour l'utilisateur, et la procédure exacte à suivre dans le portail Defender. »

Output attendu : une recommandation argumentée avec type d'isolation, impact et marche à suivre. Copilot ne réalise pas l'isolation : il prépare la décision et le geste.

Prérequis : plugin Defender XDR ; l'exécution de l'isolation requiert Defender for Endpoint et le rôle disposant de la permission Active remediation actions.

Prompt 37 — Blocage d'un indicateur

« Pour le hash SHA256 [valeur] identifié comme malveillant dans l'incident 48213, prépare le blocage : indique le type d'indicateur à créer, la portée recommandée (parc entier ou groupe d'appareils), l'action à appliquer, la durée d'expiration conseillée, et les risques de faux positif à vérifier avant application. »

Output attendu : une fiche de paramétrage d'indicateur personnalisé prête à être saisie dans les paramètres Defender. La question de la portée est cruciale : un blocage global sur un fichier également utilisé légitimement provoque une interruption de service.

Prérequis : plugin Defender XDR ; création d'indicateurs soumise aux droits de gestion des paramètres de sécurité Defender for Endpoint.

Prompt 38 — Révocation de session d'un compte compromis

« Le compte [email protected] est suspecté compromis dans l'incident 48213. Détaille la procédure complète de reprise de contrôle : révocation des sessions actives et des jetons d'actualisation, réinitialisation du mot de passe, réenregistrement MFA, vérification des règles de boîte aux lettres, des applications consenties et des méthodes d'authentification ajoutées récemment. Ordonne les étapes. »

Output attendu : une procédure ordonnée de reprise de contrôle. L'ordre compte : révoquer les jetons avant de réinitialiser le mot de passe, sinon l'attaquant conserve sa session active. La vérification des règles de boîte aux lettres et des applications consenties est le point le plus souvent oublié.

Prérequis : plugin Defender XDR ; l'exécution nécessite des droits Entra ID (administrateur d'authentification ou équivalent) et, pour les données d'identité enrichies, Defender for Identity ou Entra ID Protection.

Prompt 39 — Plan de confinement global

« Établis un plan de confinement complet pour l'incident 48213. Pour chaque entité compromise, indique l'action de confinement recommandée, sa priorité, son impact métier, son caractère réversible ou non, et le rôle habilité à l'exécuter. Présente le tout sous forme de plan d'action séquencé. »

Output attendu : un plan d'action opérationnel entité par entité. La colonne réversibilité est celle qui structure la validation hiérarchique : les actions irréversibles doivent remonter, les réversibles peuvent être déléguées à l'analyste de garde.

Prérequis : plugin Defender XDR ; exécution soumise aux rôles respectifs sur chaque produit concerné.

Prompt 40 — Rapport post-incident et retour d'expérience

« Rédige le rapport post-incident de l'incident 48213 : déroulé factuel, cause racine, mesures de confinement appliquées, mesures de remédiation, délais de détection et de réponse mesurés, défaillances de détection identifiées, et cinq recommandations d'amélioration classées par rapport effort/bénéfice. »

Output attendu : un rapport structuré exploitable en revue post-incident et comme pièce d'un dossier de conformité. Les délais mesurés et les défaillances de détection alimentent directement l'amélioration de vos règles. Si l'incident relève d'une obligation de notification, articulez ce rapport avec votre démarche de conformité NIS 2.

Prérequis : plugin Defender XDR ; relecture humaine obligatoire avant tout usage réglementaire ou contractuel.

Bonnes pratiques de prompting en contexte SOC

Quarante prompts ne servent à rien si la méthode d'utilisation est mauvaise. Quatre principes ressortent des déploiements observés.

Ancrer sur un identifiant. Un prompt qui commence par un numéro d'incident, un nom d'appareil ou un hash produit une réponse fondée sur vos données. Un prompt vague — « y a-t-il eu des attaques cette semaine ? » — produit une réponse générique. L'identifiant est ce qui déclenche l'appel de la skill Defender XDR.

Enchaîner plutôt qu'empiler. Security Copilot conserve le contexte de la session. Il est plus efficace de poser dix prompts courts qui se répondent que d'écrire un prompt monolithique de trois cents mots. La séance type suit une progression : résumé, entités, timeline, impact, hypothèse, hunting, réponse.

Exiger la source et la confiance. Ajouter « cite les alertes ou les événements sur lesquels tu t'appuies » et « donne ton niveau de confiance » transforme la vérifiabilité de la réponse. Une affirmation sans source citée doit être traitée comme une hypothèse.

Fixer une fenêtre temporelle. Sans borne explicite, Copilot applique une fenêtre par défaut qui ne correspond presque jamais à votre besoin. Précisez systématiquement la période et le fuseau horaire de référence.

Erreurs fréquentes et limites à connaître

La première erreur consiste à traiter la réponse comme une conclusion plutôt que comme une hypothèse. Copilot excelle à réduire le temps de lecture ; il ne remplace pas le jugement. Sur les attributions de famille de malware et sur les inférences de rôle d'entité, le taux d'affirmations trop confiantes justifie une vérification systématique.

La deuxième erreur est d'ignorer la fenêtre de rétention. Un hunting sur 180 jours ne renvoie rien si votre rétention Advanced Hunting est de 30 jours — et Copilot ne le signale pas toujours explicitement. Interprétez toujours un résultat vide en tenant compte de la couverture de données réelle.

La troisième erreur est la sur-confiance dans les requêtes KQL générées. Elles sont syntaxiquement correctes dans la grande majorité des cas, mais peuvent viser la mauvaise table ou omettre un filtre de bruit décisif. Le protocole minimal : exécuter d'abord sur une fenêtre courte, contrôler la volumétrie, puis élargir.

La quatrième erreur, la plus coûteuse, est la consommation non maîtrisée de SCU. Les prompts de hunting sur de larges fenêtres temporelles et les analyses de fichiers volumineux consomment davantage. Sur un SOC actif, surveillez la consommation dès les premières semaines et privilégiez des promptbooks normalisés plutôt que l'exploration libre, qui est le principal poste de dépense évitable.

Questions fréquentes

Le plugin Defender XDR est-il inclus d'office dans Security Copilot ?

Oui, c'est un plugin natif Microsoft, activé par défaut dans l'expérience autonome comme dans l'expérience embarquée du portail Defender. Il ne requiert ni installation ni clé d'API. En revanche, il n'apporte des données que sur les produits Defender réellement déployés et licenciés dans votre tenant : sans Defender for Identity, les prompts sur les identités renverront une couverture partielle. Vérifiez son statut dans le menu des sources avant toute session d'investigation.

Copilot Security peut-il isoler un endpoint automatiquement ?

Non, pas sur simple demande conversationnelle. Copilot vous fournit la recommandation, l'entité concernée et le chemin d'action, mais l'isolation réseau reste une action Defender for Endpoint soumise au RBAC, exécutée par un opérateur disposant de la permission d'actions de remédiation actives. C'est une protection délibérée : une isolation déclenchée sur une inférence erronée aurait un impact métier immédiat et non trivial à annuler.

Quelle licence faut-il pour utiliser ces prompts ?

Security Copilot se provisionne en Security Compute Units facturées à l'heure, indépendamment du nombre d'utilisateurs. À cela s'ajoutent les licences des produits interrogés : Defender for Endpoint P2 est fortement recommandé pour la profondeur de télémétrie sur les catégories 2 et 4, Defender Vulnerability Management pour les prompts d'exposition, et Defender for Office 365 P2 pour les prompts liés à la messagerie. Les prompts d'analyse de script fonctionnent sans plugin, car ils reposent sur la seule capacité d'analyse du modèle.

Les fichiers analysés en inline sortent-ils de mon environnement ?

Le contenu téléversé est traité par le service Security Copilot dans la région de votre capacité, selon les engagements de confidentialité et de traitement des données de Microsoft. Il ne quitte pas votre périmètre contractuel Microsoft, mais il quitte le périmètre restreint de vos outils d'analyse forensique. Posez une règle interne explicite excluant du téléversement les fichiers porteurs de données personnelles ou de secrets, et conservez pour les dossiers à finalité judiciaire une chaîne d'analyse tracée par vos outils dédiés.

Comment mesurer le gain réel de ces prompts en SOC ?

Suivez trois indicateurs sur trois mois. Le délai moyen entre l'ouverture d'un incident et sa qualification, qui baisse typiquement de manière marquée sur les incidents multi-alertes. Le taux d'escalade du niveau 1 vers le niveau 2, qui diminue à mesure que les analystes juniors deviennent autonomes sur l'analyse de script et le hunting. Et la consommation de SCU rapportée au nombre d'incidents traités, qui vous dit si l'usage est industrialisé ou dispersé. Sans ce troisième indicateur, le coût dérive sans que personne ne le voie.

Conclusion : de l'exploration libre au processus outillé

La valeur de Security Copilot sur Defender XDR ne vient pas du modèle, elle vient de la discipline de prompting. Un SOC qui laisse chacun improviser ses formulations obtient des résultats hétérogènes pour un coût en SCU imprévisible. Un SOC qui normalise une vingtaine de prompts, les documente et les enchaîne dans des promptbooks obtient un gain mesurable et reproductible sur le délai de qualification.

La progression recommandée tient en trois étapes. Commencez par les cinq prompts de l'encadré, sur des incidents réels, pendant deux semaines. Mesurez ensuite le délai de qualification avant et après pour objectiver le gain auprès de votre direction. Industrialisez enfin les séquences les plus rentables en promptbooks partagés, en étendant progressivement aux autres produits de la suite via notre référence de prompts par produit. L'ensemble du dossier Copilot Security est accessible depuis notre page centrale dédiée.

``` **Conformité vérifiée** : ~4 300 mots · 40 prompts (10/10/8/7/5) · chapeau premier `

` de ~180 mots · 13 H2 (ratio ~330) · 5 H3 FAQ interrogatives · `.a-retenir` avec H3 (pas de H4) et 5 prompts · 6 liens internes distincts · 2 liens externes learn.microsoft.com · pas de balises html/head/body ni de wrapper `{{define "content"}}`. Si vous voulez que je le dépose sur un chemin précis en prod, indiquez-le — je n'ai rien écrit sur disque.