Threat Hunting avancé avec Microsoft Copilot Security : prompts optimisés et MITRE ATT&CK

En 2026, la promesse d'une chasse aux menaces « automatisée par l'IA » a largement rencontré la réalité des SOC : Microsoft Security Copilot ne transforme pas un analyste de niveau 1 en threat hunter, mais il divise par trois le temps de production d'une requête KQL complexe et par cinq le temps d'enrichissement d'un indicateur. La différence entre les équipes qui en tirent un gain mesurable et celles qui consomment des SCU sans résultat tient à une seule variable : la qualité et la structure des prompts. Un prompt vague produit une réponse générique, coûteuse en unités de calcul et inexploitable en production. Un prompt ancré sur une technique MITRE ATT&CK précise, contraint sur un schéma de table Defender XDR et assorti d'une hypothèse de chasse explicite produit une requête directement déployable en règle de détection personnalisée. Cet article décrit la méthodologie que nous appliquons en clientèle : cartographie tactique ATT&CK vers capacités Copilot, bibliothèque de prompts par tactique, génération KQL contrôlée, intégration Defender Threat Intelligence et ATT&CK Navigator, méthodologie APT en cinq phases, et métriques permettant de démontrer un retour sur investissement à un COMEX.

Philosophie du threat hunting assisté par IA : accélérateur, pas remplaçant

La chasse aux menaces repose sur un postulat que le langage naturel ne dissout pas : un hunter formule une hypothèse falsifiable sur la présence d'un adversaire dans un périmètre donné, puis conçoit un test permettant de l'infirmer ou de la confirmer. Security Copilot n'intervient jamais sur la formulation de l'hypothèse — c'est un travail de contexte métier, de connaissance de l'architecture et de renseignement adverse. Il intervient massivement sur l'exécution du test : traduction de l'hypothèse en requête, enrichissement des résultats, corrélation multi-sources et rédaction du livrable.

Ce que Security Copilot change réellement dans la boucle de chasse

Sur une campagne de chasse standard de cinq jours, la répartition d'effort observée sans assistance IA se décompose approximativement ainsi : 15 % de formulation d'hypothèses, 40 % d'écriture et de débogage de requêtes, 25 % d'enrichissement et de triage des résultats, 20 % de documentation et de conversion en détections. Security Copilot attaque frontalement les deux blocs médians, soit environ 65 % de l'effort. Dans nos déploiements clients, l'écriture d'une requête KQL multi-tables avec jointure temporelle passe typiquement de 45 minutes à 12 minutes, débogage inclus. L'enrichissement d'un lot de 30 indicateurs via le plugin Microsoft Defender Threat Intelligence passe de deux heures de consultation manuelle à moins de vingt minutes.

Le gain n'est pas linéaire selon le niveau de l'analyste. Un hunter de niveau 3 y gagne un facteur d'accélération ; un analyste de niveau 1 y gagne surtout une capacité à produire du contenu qu'il ne sait pas valider, ce qui constitue un risque opérationnel. La documentation Microsoft présente le produit comme une solution d'analyse de la sécurité en langage naturel destinée à augmenter l'efficacité des défenseurs — le verbe « augmenter » est à prendre au pied de la lettre : l'augmentation d'une compétence nulle reste nulle.

Le piège de l'hypothèse générée par le modèle

Une dérive fréquente consiste à demander à Copilot « quelles menaces devrais-je chasser dans mon environnement ». Le modèle produira une liste plausible, largement dérivée des rapports d'analyse des menaces disponibles, mais totalement décorrélée de votre surface d'exposition réelle, de vos flux métier et de votre modélisation d'adversaire. Cette liste consomme des SCU et génère une activité de chasse qui donne une impression de couverture sans en fournir la substance. L'hypothèse doit provenir d'une source externe au modèle : renseignement sectoriel, résultat d'un pentest Active Directory, retour d'un exercice red team, ou observation d'une anomalie dans les données.

Le principe de non-délégation de la validation

Security Copilot fonctionne par grounding : le prompt utilisateur est prétraité, enrichi via les plugins, envoyé au modèle de langage, puis la réponse est post-traitée avec un nouvel appel aux plugins. Cette architecture réduit l'hallucination sans l'éliminer. Concrètement, sur les requêtes KQL générées, nous observons un taux d'erreur de syntaxe ou de schéma d'environ 15 à 20 % sur les requêtes multi-tables complexes, et un taux de « colonne inexistante » non négligeable lorsque le prompt mentionne une table peu documentée. La règle opérationnelle est absolue : aucune requête générée n'est promue en règle de détection personnalisée sans exécution en mode chasse avancée, revue de la logique par un humain, et évaluation du volume de faux positifs sur une fenêtre de 30 jours.

Mapper les tactiques MITRE ATT&CK aux capacités de Copilot Security

Toute démarche sérieuse de chasse assistée commence par une cartographie explicite : quelle tactique ATT&CK est couverte par quelle source de données, elle-même exposée par quel plugin Security Copilot. Sans cette matrice, les prompts sont formulés à l'aveugle et échouent silencieusement — le modèle répondra sans indiquer qu'il ne dispose pas de la télémétrie nécessaire.

Cartographie plugin vers tactique

Les plugins sont, selon la documentation officielle, des collections d'outils (ou compétences) activables qui donnent au modèle accès à des ressources externes. La correspondance opérationnelle avec les tactiques ATT&CK s'établit comme suit :

• Initial Access (TA0001) — plugin Microsoft Defender XDR (tables EmailEvents, EmailAttachmentInfo, UrlClickEvents) et plugin Microsoft Entra pour les authentifications initiales.
• Execution (TA0002) et Persistence (TA0003) — Defender XDR via DeviceProcessEvents, DeviceRegistryEvents, DeviceFileEvents ; plugin Intune pour les scripts de configuration détournés.
• Privilege Escalation (TA0004) et Credential Access (TA0006) — Defender for Identity via IdentityLogonEvents, IdentityDirectoryEvents, IdentityQueryEvents ; Entra ID pour les élévations de rôles privilégiés.
• Defense Evasion (TA0005) — DeviceProcessEvents, DeviceImageLoadEvents, et journaux d'altération de la protection contre les falsifications.
• Lateral Movement (TA0008) — DeviceLogonEvents, DeviceNetworkEvents, IdentityLogonEvents.
• Collection (TA0009) et Exfiltration (TA0010) — plugin Microsoft Defender for Cloud Apps via CloudAppEvents, et Purview pour la classification des données mouvantes.
• Command and Control (TA0011) — DeviceNetworkEvents croisé avec le plugin Microsoft Defender Threat Intelligence pour la réputation d'infrastructure.

Les zones aveugles à documenter avant de chasser

Trois angles morts reviennent systématiquement en audit. Premièrement, les tactiques Reconnaissance (TA0043) et Resource Development (TA0042) sont pré-compromission : aucune télémétrie interne ne les couvre, seul le renseignement externe MDTI y répond, et uniquement de manière rétrospective. Deuxièmement, la rétention : la chasse avancée dans Defender XDR conserve trente jours de télémétrie ; toute hypothèse portant sur un dwell time supérieur exige que les tables soient déversées dans un espace de travail Microsoft Sentinel avec une rétention étendue. Un prompt demandant une chasse sur quatre-vingt-dix jours dans le portail Defender retournera un résultat vide interprété à tort comme une absence de compromission. Troisièmement, la couverture d'onboarding : un parc où 12 % des serveurs ne sont pas intégrés à Defender for Endpoint produit une matrice de couverture ATT&CK optimiste et fausse.

Construire sa matrice de couverture interne

Le livrable attendu est un tableau à quatre colonnes — technique ATT&CK, source de données requise, source réellement disponible, plugin Copilot mobilisable — maintenu par l'équipe de chasse et révisé trimestriellement. Security Copilot peut accélérer sa construction avec un prompt du type : Pour la technique T1558.003 (Kerberoasting), liste les sources de données ATT&CK requises, indique pour chacune la table Defender XDR ou Sentinel correspondante, et signale les cas où aucune table Microsoft native ne couvre la source. Le résultat doit être vérifié, mais il fait gagner un temps considérable sur les 200+ techniques d'une matrice Enterprise complète.

Bibliothèque de prompts efficaces par tactique MITRE

Un prompt de chasse performant n'est pas une question posée en langage naturel : c'est une spécification. Nos mesures internes montrent qu'un prompt structuré consomme en moyenne 40 % de SCU en moins qu'une série de prompts conversationnels aboutissant au même résultat, parce qu'il évite les cycles de reformulation.

Anatomie d'un prompt de chasse performant

Cinq composants sont non négociables. Le rôle : préciser que la réponse s'adresse à un analyste SOC niveau 3 fixe le registre technique et supprime les explications superflues. L'ancrage ATT&CK : citer l'identifiant exact de la technique et de la sous-technique, pas son nom seul. La contrainte de source : nommer explicitement les tables autorisées. La contrainte de sortie : imposer le format (requête KQL seule, tableau, liste d'IOC). Le périmètre temporel et le seuil : fenêtre d'analyse et critère de bruit acceptable. Un prompt qui omet la contrainte de source produit dans plus de la moitié des cas une requête référençant une table absente du tenant.

Initial Access et Persistence

Pour la chasse au phishing de type consentement OAuth illicite (T1566, puis T1098.003) : En tant qu'analyste SOC N3, génère une requête KQL sur CloudAppEvents identifiant les octrois de consentement à des applications d'entreprise créées depuis moins de 14 jours, ayant obtenu des permissions Mail.Read ou Mail.ReadWrite, et consenties par plus de 3 utilisateurs distincts. Retourne uniquement la requête, sans commentaire.

Pour la persistance par tâche planifiée (T1053.005), le prompt gagne à imposer une exclusion de référence : Génère une requête KQL sur DeviceProcessEvents détectant les créations de tâches planifiées via schtasks.exe ou Register-ScheduledTask, en excluant les processus parents signés par Microsoft et les comptes de service se terminant par $. Ajoute une colonne de score basée sur la présence d'encodage base64 dans la ligne de commande. La demande explicite d'un scoring évite le retour d'un jeu de résultats non priorisé.

Credential Access et Lateral Movement

Le Kerberoasting reste la technique la plus productive en chasse Active Directory. Un prompt efficace : Génère une requête KQL sur SecurityEvent détectant les demandes de tickets de service Kerberos (EventID 4769) avec TicketEncryptionType 0x17, agrégées par compte source, en ne retournant que les comptes ayant demandé plus de 8 SPN distincts en moins de 10 minutes. Le seuil et la fenêtre sont indispensables : sans eux, la requête retourne l'intégralité du trafic Kerberos d'un domaine. Le même raisonnement s'applique à l'AS-REP Roasting (T1558.004) en pivotant sur l'EventID 4768 avec PreAuthType à 0.

Pour le mouvement latéral par WMI ou WinRM (T1021.006, T1047), demandez explicitement une jointure : Génère une requête KQL corrélant DeviceNetworkEvents (ports 5985/5986) et DeviceProcessEvents (wsmprovhost.exe) sur DeviceId dans une fenêtre de 5 minutes, pour identifier les sessions WinRM entrantes suivies d'une exécution de processus enfant non signé. C'est sur ce type de corrélation temporelle multi-tables que Copilot fait gagner le plus de temps, et c'est aussi là qu'il faut relire la logique de jointure avec le plus d'attention. Ces mêmes chaînes sont ensuite exploitables dans la reconstruction des chaînes d'attaque Defender XDR.

Defense Evasion, C2 et Exfiltration

Pour l'évasion par LOLBins (T1218), la valeur ajoutée du modèle est de connaître la liste étendue des binaires détournables : Liste les 15 binaires signés Microsoft les plus fréquemment abusés pour l'exécution de code arbitraire selon MITRE ATT&CK T1218, puis génère une requête KQL unique sur DeviceProcessEvents recherchant leur exécution avec des arguments réseau (http, ftp, //) et un processus parent Office ou navigateur.

Pour la détection de balisage C2 (T1071.001), le prompt doit expliciter la méthode statistique attendue, sans quoi le modèle produit une simple liste de connexions : Génère une requête KQL sur DeviceNetworkEvents calculant la variance des intervalles entre connexions sortantes par couple DeviceId/RemoteUrl sur 24 heures, et retournant les couples avec au moins 50 connexions et un coefficient de variation inférieur à 0,15, signature d'un balisage régulier. Le résultat exige un ajustement du seuil sur votre environnement — les agents de télémétrie légitimes présentent la même signature.

Industrialiser via les promptbooks

Un prompt validé ne doit jamais rester dans l'historique d'un analyste. Les promptbooks permettent d'enchaîner une séquence d'invites paramétrées : par exemple, phase 1 récupération des incidents actifs liés à une technique, phase 2 extraction des entités, phase 3 enrichissement MDTI, phase 4 génération d'une requête de chasse rétrospective, phase 5 rédaction du résumé exécutif. Un promptbook stabilisé produit un résultat reproductible et un coût SCU prévisible, ce qui n'est jamais le cas d'une conversation improvisée. Nous recommandons de versionner les promptbooks dans le dépôt Git de l'équipe de détection, au même titre que les règles analytiques.

Génération KQL ciblée : de la requête basique à la détection avancée

La génération KQL est le cas d'usage le plus mature de Security Copilot, explicitement mis en avant par Microsoft comme permettant d'éliminer l'écriture manuelle de requêtes. Elle est aussi celle qui exige le plus de discipline méthodologique.

La structure du prompt KQL en cinq contraintes

Le modèle de prompt que nous imposons en formation comporte systématiquement : la ou les tables autorisées, la fenêtre temporelle, les colonnes de sortie exigées, le critère d'exclusion du bruit connu, et l'instruction de ne retourner que du code. Exemple complet pour la détection de dumping LSASS (T1003.001) : Tables autorisées : DeviceProcessEvents et DeviceEvents. Fenêtre : 30 jours. Objectif : détecter les accès en lecture à la mémoire de lsass.exe hors processus de sécurité connus. Exclusions : processus signés par Microsoft Corporation ou par notre éditeur EDR. Sortie : DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName, Timestamp, triés par fréquence croissante. Retourne uniquement la requête KQL. La demande de tri par fréquence croissante est un détail qui change tout : elle place les occurrences rares — celles qui intéressent le hunter — en tête plutôt qu'en queue.

Le raffinement itératif contrôlé

La première requête est rarement déployable. Le raffinement s'effectue par instructions incrémentales sur la même session, ce qui préserve le contexte et limite la consommation : Ajoute une jointure avec DeviceInfo pour ne conserver que les machines dont le rôle est serveur. Puis : Remplace le summarize par une détection d'anomalie basée sur series_decompose_anomalies sur une baseline de 14 jours. Puis : Reformate la requête pour qu'elle soit compatible avec une règle de détection personnalisée Defender XDR, en incluant les colonnes d'entité requises pour l'alerte. Cette dernière instruction est cruciale : une règle de détection personnalisée exige la présence de colonnes d'identification d'entité (DeviceId, AccountObjectId, ReportId, Timestamp), et le modèle les omet par défaut.

Les erreurs récurrentes à intercepter

Quatre familles d'erreurs représentent l'essentiel des correctifs manuels. Les colonnes inexistantes ou renommées, en particulier sur les tables Identity et les tables en préversion dont le schéma évolue. Les jointures sans borne temporelle, qui produisent des requêtes dépassant le quota d'exécution sur un parc de plus de 10 000 postes. L'usage de join là où union suivi d'un summarize serait bien plus performant. Enfin, les expressions régulières trop permissives dans les filtres matches regex, générant un volume de faux positifs ingérable. Un contrôle systématique de ces quatre points avant tout déploiement évite l'essentiel des incidents de performance, particulièrement lorsque la requête est portée vers Sentinel pour une investigation d'incidents avec Sentinel sur une rétention longue.

Intégration avec Defender Threat Intelligence et MITRE Navigator

La chasse gagne un ordre de grandeur en pertinence lorsqu'elle est pilotée par le renseignement plutôt que par l'anomalie seule. Security Copilot accède aux articles et profils Intel de Microsoft Defender Threat Intelligence ainsi qu'aux rapports d'analyse des menaces de Defender XDR via ses plugins natifs.

Le plugin MDTI comme socle d'enrichissement

Le pattern le plus rentable consiste à partir d'un profil d'acteur et à redescendre vers la télémétrie : Résume les techniques MITRE ATT&CK associées à l'acteur de menace [nom] selon les profils Intel Microsoft Defender Threat Intelligence, puis pour chaque technique indique la table Defender XDR permettant de la chasser et une requête KQL de détection. Priorise les techniques observées dans les campagnes des 6 derniers mois. La contrainte de fraîcheur évite de chasser des TTP obsolètes. Ce même plugin permet le pivot d'infrastructure : à partir d'un domaine C2, obtenir les certificats TLS associés, les résolutions passives et les autres domaines partageant la même infrastructure — ce qui produit une liste d'IOC à confronter immédiatement à DeviceNetworkEvents.

Produire une couche ATT&CK Navigator exploitable

ATT&CK Navigator consomme des fichiers de couche au format JSON. Security Copilot peut les générer, mais le prompt doit être explicite sur la structure attendue : Génère un fichier de couche ATT&CK Navigator au format JSON, version domaine enterprise-attack, contenant les techniques suivantes avec un score de 100 et un commentaire indiquant la règle de détection couvrante : [liste]. Vérifiez systématiquement la conformité du JSON produit avant import — le schéma de couche évolue et le modèle peut produire une version antérieure. La superposition de deux couches — techniques couvertes par vos détections et techniques observées chez votre adversaire de référence — matérialise instantanément votre déficit de couverture, et constitue le support de priorisation le plus efficace pour un comité sécurité.

Boucler le cycle : de l'IOC à la détection pérenne

Un IOC enrichi et chassé sans conversion en détection est un effort perdu. La boucle complète comprend quatre étapes : ingestion du renseignement, chasse rétrospective sur la rétention maximale disponible, création d'une règle de détection personnalisée si un pattern comportemental est identifiable, et documentation de la technique ATT&CK couverte dans la matrice interne. Security Copilot intervient sur les étapes 2 et 3 ; les étapes 1 et 4 relèvent de la gouvernance de l'équipe. Une chasse qui ne produit pas de détection nouvelle ni d'exclusion documentée n'a pas de valeur capitalisable.

Chasse aux APT : méthodologie en 5 phases avec Copilot Security

Face à un acteur étatique ou à un groupe d'accès initial sophistiqué, la chasse opportuniste ne suffit pas. La méthodologie suivante structure une campagne de deux à trois semaines.

Phase 1 — Modélisation de l'adversaire

Sélection d'un ou deux acteurs pertinents pour votre secteur et votre géographie, extraction de leur matrice TTP via MDTI, et confrontation à votre surface d'attaque réelle. Livrable : une liste ordonnée de dix à quinze techniques à chasser. Prompt d'appui : Compare les techniques ATT&CK des acteurs [X] et [Y] ciblant le secteur [secteur] en Europe, identifie les techniques communes aux deux, et classe-les par difficulté de détection avec les sources de données Microsoft disponibles.

Phase 2 — Formulation des hypothèses falsifiables

Chaque technique retenue devient une hypothèse testable au format : « si l'adversaire a employé T1550.002 dans notre environnement, alors nous devrions observer [artefact] dans [table] sur [fenêtre] ». Cette phase reste humaine. Copilot peut en revanche être sollicité pour identifier les artefacts résiduels d'une technique : Pour T1550.002 (Pass-the-Hash), liste les artefacts forensiques observables côté endpoint et côté annuaire, en distinguant ceux visibles dans la télémétrie Defender de ceux nécessitant un accès aux journaux Windows bruts.

Phase 3 — Exécution et triage

Génération et exécution des requêtes, puis triage. C'est ici que la consommation SCU culmine. Discipline recommandée : exécuter les requêtes en chasse avancée hors Copilot, et ne solliciter le modèle que sur les jeux de résultats non triviaux. Faire analyser par Copilot un tableau de 4 000 lignes est un gaspillage ; lui soumettre les 12 lignes anormales avec le contexte de l'hypothèse produit une analyse utile.

Phase 4 — Reconstruction et corrélation

Les signaux confirmés sont assemblés en chronologie d'attaque. Prompt type : À partir des éléments suivants (horodatages, machines, comptes, processus), reconstruis une chronologie d'attaque, mappe chaque étape à une technique ATT&CK, et identifie les étapes manquantes de la chaîne qui devraient logiquement exister entre l'accès initial constaté et l'exécution observée. L'identification des maillons manquants est la valeur la plus sous-exploitée du modèle : elle oriente directement la suite de la chasse.

Phase 5 — Capitalisation

Conversion en règles de détection, mise à jour de la couche Navigator, rédaction du rapport et de la synthèse exécutive. Security Copilot excelle sur la production du rapport à deux niveaux de lecture — technique pour l'équipe, synthétique pour la direction — à partir des mêmes données. Comptez une réduction de 60 à 70 % du temps de rédaction, à condition de fournir en entrée des faits structurés et non une conversation à faire résumer.

Métriques de performance du threat hunting assisté par IA

Sans instrumentation, l'usage de Security Copilot reste une conviction. Trois familles de métriques sont à instrumenter dès le premier trimestre.

Métriques d'efficacité de la chasse

Le nombre de détections nouvelles produites par campagne est l'indicateur maître : une campagne qui ne génère aucune règle nouvelle signale soit une couverture déjà mature, soit des hypothèses mal choisies. S'y ajoutent le nombre de techniques ATT&CK nouvellement couvertes, le délai moyen entre publication d'un renseignement et chasse rétrospective effectuée — un objectif de 48 heures est atteignable avec un promptbook dédié — et le taux de conversion hypothèse vers détection, dont une valeur saine se situe entre 20 et 30 %.

Métriques de consommation et de coût

Le modèle de facturation repose sur des Security Compute Units provisionnées à l'heure, avec possibilité de provisionner de la capacité additionnelle pour absorber les pics. La métrique décisive est le coût SCU par détection produite, et non le volume de SCU consommé. Une équipe consommant beaucoup en produisant des détections est performante ; une équipe consommant peu sans rien produire ne l'est pas. Instrumentez également la répartition de consommation par cas d'usage — chasse, investigation, reporting — pour identifier les usages à faible rendement. Les mécanismes de provisionnement et d'optimisation sont détaillés dans notre analyse de l'architecture et consommation SCU.

Métriques de qualité des prompts

Trois indicateurs pilotent l'amélioration continue : le taux de requêtes KQL exploitables au premier essai — un bon niveau de maturité se situe au-delà de 70 % —, le nombre moyen d'itérations par requête produite, et la part de prompts issus de la bibliothèque validée par rapport aux prompts improvisés. Cette dernière métrique est le meilleur prédicteur de la performance globale : les équipes dont plus de 60 % des prompts proviennent d'une bibliothèque versionnée obtiennent des résultats nettement plus reproductibles et un coût unitaire inférieur. Une revue mensuelle de la bibliothèque, avec retrait des prompts obsolètes et promotion des prompts découverts en session, suffit à maintenir cette dynamique.

Questions fréquentes

Security Copilot peut-il remplacer un threat hunter expérimenté ?

Non, et la question est mal posée. Le modèle ne formule pas d'hypothèse de chasse pertinente parce qu'il ignore votre contexte métier, votre architecture réelle et votre modélisation d'adversaire. Il accélère l'exécution — génération de requêtes, enrichissement, corrélation, rédaction — soit environ 65 % de l'effort d'une campagne. Un hunter expérimenté y gagne un facteur d'accélération significatif ; un analyste junior y gagne surtout la capacité de produire du contenu qu'il ne sait pas valider, ce qui constitue un risque opérationnel réel. Le prérequis reste la compétence humaine en KQL et en analyse comportementale.

Quelle est la fiabilité réelle des requêtes KQL générées par Security Copilot ?

Sur des requêtes mono-table simples, le taux d'exploitabilité au premier essai dépasse 85 % dans nos mesures. Sur des requêtes multi-tables avec jointures temporelles et agrégations statistiques, il chute nettement, avec 15 à 20 % d'erreurs de syntaxe ou de schéma. Les erreurs les plus fréquentes sont les colonnes inexistantes sur les tables en préversion, les jointures sans borne temporelle et les expressions régulières trop permissives. Aucune requête générée ne doit être promue en règle de détection sans exécution en chasse avancée, revue humaine de la logique et évaluation du volume de faux positifs.

Comment maîtriser la consommation de SCU pendant une campagne de chasse ?

Trois leviers. Utiliser des prompts structurés plutôt que conversationnels : la contrainte explicite de tables, de format et de périmètre évite les cycles de reformulation et réduit la consommation d'environ 40 %. Exécuter les requêtes lourdes en chasse avancée hors Copilot et ne soumettre au modèle que les jeux de résultats déjà filtrés. Enfin, industrialiser via des promptbooks versionnés, dont le coût est prévisible, plutôt que de laisser chaque analyste improviser. La métrique de pilotage est le coût SCU par détection produite, pas le volume brut consommé.

Faut-il Microsoft Sentinel en plus de Defender XDR pour chasser efficacement ?

Cela dépend de votre horizon temporel de chasse. La chasse avancée dans Defender XDR expose trente jours de télémétrie, ce qui suffit pour des campagnes réactives mais interdit toute investigation sur un dwell time long — or la médiane de détection d'un acteur sophistiqué dépasse souvent ce seuil. Pour une chasse APT sérieuse, le déversement des tables Defender vers un espace de travail Sentinel avec rétention étendue est nécessaire. Sentinel apporte également l'ingestion de sources non-Microsoft, indispensable si votre périmètre inclut des équipements réseau ou des systèmes industriels.

Comment structurer une bibliothèque de prompts de chasse maintenable ?

Organisez-la par tactique ATT&CK, avec pour chaque prompt cinq métadonnées : technique couverte, tables requises, date de dernière validation, taux d'exploitabilité observé et auteur. Versionnez-la dans le dépôt Git de l'équipe de détection, au même titre que les règles analytiques, avec revue par pair avant intégration. Instaurez une revue mensuelle retirant les prompts obsolètes — les schémas de tables évoluent — et promouvant les prompts découverts en session. L'objectif de maturité est que plus de 60 % des prompts exécutés proviennent de la bibliothèque validée.