Copilot Security + Microsoft Sentinel : investigation d'incidents en profondeur

Fin 2025, un SOC de taille moyenne ingérait déjà entre 400 Go et 2 To de télémétrie par jour dans Microsoft Sentinel, pour un ratio d'alertes réellement investiguées qui dépassait rarement 60 %. Le problème n'a jamais été la détection : il a toujours été le temps de contextualisation. Un analyste de niveau 2 passe en moyenne 25 à 40 minutes à reconstituer manuellement une chaîne d'attaque à partir de six tables KQL différentes, à croiser des identités Entra ID avec des événements DeviceLogonEvents, puis à qualifier des IOC dans trois consoles distinctes. L'association de Copilot Security et de Microsoft Sentinel attaque précisément ce goulot d'étranglement, en déplaçant l'effort du parsing manuel vers la validation d'hypothèses. En 2026, la question pour les équipes sécurité n'est plus « faut-il activer Security Copilot ? » mais « quels workflows d'investigation lui déléguer sans dégrader la qualité de la qualification ? ». Cet article détaille l'intégration réelle, les prompts qui fonctionnent, les requêtes produites, et surtout les limites que tout ingénieur Sentinel doit connaître avant de laisser un modèle génératif écrire ses règles de détection.

L'intégration native Sentinel/Copilot : ce qui est activé automatiquement

Microsoft Security Copilot — nom produit officiel de ce que le marché appelle communément Copilot Security — se présente sous deux formes distinctes qu'il faut impérativement différencier avant tout déploiement. La documentation Microsoft de référence décrit une expérience autonome (le portail securitycopilot.microsoft.com) et des expériences intégrées présentes directement dans les produits de sécurité Microsoft. Cette distinction n'est pas cosmétique : elle conditionne les plugins disponibles, le contexte injecté dans le prompt et la facturation.

Le plugin Microsoft Sentinel et son périmètre exact

Le plugin Microsoft Sentinel est préinstallé et activé par défaut dès lors que le tenant dispose d'un espace de travail Sentinel et que l'utilisateur possède les droits adéquats. Concrètement, il expose des compétences (skills) qui interrogent les incidents Sentinel, exécutent des requêtes KQL sur l'espace de travail Log Analytics et récupèrent les entités associées à un incident. Comme le précise la vue d'ensemble des plugins, Security Copilot utilise automatiquement les plugins disponibles sans configuration additionnelle : l'orchestrateur sélectionne lui-même la compétence pertinente en fonction de la formulation du prompt.

Point de vigilance opérationnel : depuis la convergence de Microsoft Sentinel dans le portail Defender, l'expérience intégrée que voient la plupart des analystes est celle de Defender XDR, pas celle de Sentinel en tant que ressource Azure. Le panneau Copilot latéral d'une page d'incident consomme des compétences XDR même lorsque l'incident provient d'une règle analytique Sentinel. Si vous avez besoin d'interroger explicitement des tables custom (logs syslog, CEF, tables _CL), il faut passer par l'expérience autonome et nommer l'espace de travail dans le prompt.

Ce qui n'est pas activé automatiquement

Trois éléments réclament une action explicite. D'abord le provisionnement des SCU (Security Compute Units), unité de capacité horaire qui conditionne l'exécution des prompts ; sans capacité provisionnée dans la région adéquate, aucune expérience intégrée ne s'affiche. Ensuite l'attribution des rôles : un analyste doit disposer d'un rôle Security Copilot (contributeur ou propriétaire) en plus de ses permissions Azure RBAC sur l'espace de travail Sentinel — Copilot applique un flux d'authentification on-behalf-of, il ne voit donc jamais plus de données que l'utilisateur qui l'interroge. Enfin les plugins non-Microsoft et personnalisés, qui doivent être ajoutés manuellement et dont les produits sous-jacents s'achètent séparément. Nous détaillons ces mécanismes de capacité et d'extension dans notre analyse de l'architecture de Copilot Security.

En pratique, sur les tenants que nous auditons, l'erreur la plus fréquente reste l'attribution du rôle Copilot à l'ensemble du groupe « SOC » sans revue des permissions Sentinel sous-jacentes. Résultat : des analystes N1 obtiennent des réponses vides ou tronquées et concluent à tort que « Copilot ne voit pas les logs », alors qu'il s'agit d'un défaut de RBAC sur le Log Analytics Workspace.

Génération de requêtes KQL avancées par langage naturel : prompts efficaces

La génération de KQL est le cas d'usage à plus fort retour immédiat, et celui que Microsoft met explicitement en avant : éliminer la nécessité d'écrire manuellement des requêtes pour permettre à chaque membre de l'équipe d'exécuter des tâches techniques. Mais la qualité du KQL produit est directement proportionnelle à la précision du prompt. Un prompt vague produit une requête syntaxiquement valide et sémantiquement inutile.

Anatomie d'un prompt KQL exploitable

Un prompt efficace comporte systématiquement quatre composants : la table cible, la fenêtre temporelle, la condition métier et le format de sortie attendu. Comparez ces deux formulations. Prompt faible : « Trouve les connexions suspectes des 7 derniers jours ». Prompt exploitable : « Génère une requête KQL sur la table SigninLogs des 7 derniers jours qui identifie les comptes ayant réussi une authentification depuis plus de 3 pays distincts, en excluant les ResultType différents de 0, avec en sortie UserPrincipalName, le nombre de pays, la liste des IP et le premier/dernier timestamp, triés par nombre de pays décroissant ».

La seconde formulation produit une requête directement exécutable, du type : SigninLogs | where TimeGenerated > ago(7d) | where ResultType == 0 | summarize CountryCount = dcount(tostring(LocationDetails.countryOrRegion)), Countries = make_set(tostring(LocationDetails.countryOrRegion)), IPs = make_set(IPAddress, 100), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by UserPrincipalName | where CountryCount >= 3 | sort by CountryCount desc

Les patterns de prompt qui débloquent le KQL avancé

Trois patterns donnent des résultats nettement supérieurs sur les requêtes complexes. Le premier est le prompt itératif de raffinement : on demande une requête simple, puis on enchaîne « ajoute une jointure avec IdentityInfo pour récupérer le département et le manager » ou « remplace le summarize par une détection de série temporelle avec series_decompose_anomalies ». Copilot conserve le contexte de session et modifie la requête existante plutôt que d'en régénérer une depuis zéro.

Le deuxième est le prompt ancré sur un ID d'incident : « À partir de l'incident 48213, génère une requête KQL qui recherche toutes les autres occurrences des IOC de cet incident sur les 30 derniers jours dans DeviceNetworkEvents et DeviceFileEvents ». Le plugin Sentinel récupère alors les entités réelles de l'incident et les injecte dans la requête, ce qui supprime l'étape de copier-coller d'indicateurs — source d'erreur classique.

Le troisième est le prompt contraint par le schéma : « Utilise uniquement les colonnes existantes de la table AADNonInteractiveUserSignInLogs ; si une colonne nécessaire n'existe pas, indique-le au lieu de l'inventer ». Cette contrainte explicite réduit significativement les hallucinations de colonnes, que nous détaillons plus loin.

Traduction et migration de règles

Cas d'usage sous-estimé : la traduction de contenu tiers vers KQL. Sur une migration Splunk vers Sentinel menée sur un parc de 190 règles SPL, l'usage de prompts de type « Convertis cette recherche SPL en KQL équivalent pour Microsoft Sentinel en précisant les tables sources correspondantes » a produit une base fonctionnelle sur environ deux tiers des règles, les logiques de corrélation multi-index et les macros SPL restant à réécrire manuellement. Le gain n'est pas la traduction automatique intégrale mais la suppression du travail de squelette. Même logique pour les règles Sigma : Copilot produit un KQL correct pour les détections mono-table, beaucoup moins fiable dès qu'il faut résoudre des champs de taxonomie propres à un connecteur.

Investigation d'incidents : du résumé automatique à l'analyse des IOC

C'est ici que l'intégration change réellement la posture d'un SOC. L'investigation assistée repose sur trois briques enchaînées : le résumé d'incident, l'enrichissement des indicateurs et l'analyse de code.

Le résumé d'incident : ce qu'il contient vraiment

Sur une page d'incident, le résumé généré agrège les alertes constitutives, les entités impliquées (comptes, hôtes, IP, fichiers, URL), la chronologie et un mapping MITRE ATT&CK des techniques observées. Sa vraie valeur n'est pas de remplacer la lecture de l'incident, mais de produire en quelques secondes un état des lieux structuré pour un analyste qui prend l'incident en cours de shift ou en escalade. Le passage de relais entre équipes, historiquement le maillon faible des SOC 24/7, en bénéficie directement.

Un prompt de complément systématiquement utile après le résumé : « Liste les 5 questions auxquelles je dois répondre pour qualifier cet incident en vrai positif ou faux positif, avec pour chacune la requête KQL correspondante ». La réponse structure l'investigation, et surtout elle est vérifiable — un analyste expérimenté juge en trente secondes si les questions sont pertinentes.

Enrichissement des IOC et threat intelligence

Le plugin Microsoft Defender Threat Intelligence donne accès aux profils d'acteurs, aux articles Intel et aux infrastructures connues. Un prompt du type « Pour chacune des IP externes de cet incident, indique la réputation MDTI, l'ASN, le pays, si elle est associée à un acteur suivi, et croise-la avec ThreatIntelligenceIndicator dans mon espace de travail » produit en une passe ce qui demandait trois consoles. La qualification d'une IP de sortie Tor, d'un nœud de proxy résidentiel ou d'une infrastructure de commande et contrôle connue devient une opération de trente secondes.

Attention toutefois : l'absence de réputation négative n'est pas une preuve d'innocuité, et Copilot a tendance à formuler des réponses rassurantes en l'absence de données. Une IP « sans indicateur connu » sur une infrastructure fraîchement enregistrée est précisément le profil d'une campagne ciblée. La lecture correcte est « aucune donnée », pas « pas de risque ».

Analyse de scripts et de lignes de commande

La désobfuscation reste l'usage le plus spectaculaire. Soumettre un blob PowerShell encodé en Base64 extrait de DeviceProcessEvents et demander « décode ce script, explique son comportement étape par étape, identifie les techniques MITRE et liste les IOC réseau et fichier qu'il génère » donne un résultat qui, sur du code d'attaquant standard (loaders, stagers, scripts de reconnaissance), fait gagner quinze à trente minutes par échantillon. Sur du code fortement obfusqué ou packé, en revanche, la réponse devient descriptive et générique — un signal qu'il faut basculer sur une analyse dynamique en sandbox. Cette logique de reconstruction de chaîne d'attaque se prolonge dans le portail unifié, comme nous l'exposons dans notre article sur l'investigation dans Defender XDR.

Corrélation UEBA et comportements anormaux détectés par Copilot

Microsoft Sentinel UEBA alimente deux tables clés : BehaviorAnalytics, qui porte les scores d'investigation et les preuves d'activité anormale, et UserPeerAnalytics, qui établit les groupes de pairs. Ces tables sont notoirement sous-exploitées, principalement parce que leur schéma imbriqué (dynamic) décourage l'écriture manuelle de requêtes. C'est exactement le type de friction que la génération assistée supprime.

Exploiter BehaviorAnalytics sans écrire de KQL

Un prompt opérationnel : « Génère une requête KQL sur BehaviorAnalytics pour les 14 derniers jours qui retourne les utilisateurs dont le InvestigationPriority cumulé dépasse 20, avec le détail des ActivityType, les preuves d'anomalie associées, et enrichis avec le département depuis IdentityInfo ». Le résultat exploite les champs ActivityInsights et UsersInsights que peu d'ingénieurs manipulent de mémoire, avec des accès du type tostring(ActivityInsights.FirstTimeUserLoggedOnToDevice).

L'intérêt réel se manifeste en corrélation. Le prompt « Croise les utilisateurs avec un InvestigationPriority élevé cette semaine avec les comptes ayant déclenché des alertes Defender for Identity, et indique lesquels ont également modifié leur méthode MFA dans AuditLogs » produit une hypothèse d'investigation qui, écrite à la main, représente une trentaine de lignes de KQL avec trois jointures et deux normalisations de casse sur les UPN.

Ce que Copilot détecte — et ce qu'il ne détecte pas

Formulons-le sans ambiguïté : Copilot ne détecte rien. Il n'existe pas de moteur d'analyse comportementale propre à Security Copilot qui viendrait s'ajouter à UEBA. Ce que le modèle apporte, c'est la capacité à interpréter et corréler des signaux déjà produits par Sentinel UEBA, Defender for Identity et Entra ID Protection, et à les restituer sous forme narrative. La distinction est capitale pour un RSSI qui construit un dossier d'investissement : Security Copilot n'améliore pas le taux de détection, il améliore le temps et la qualité de la qualification. Si votre couverture de détection est faible, Copilot ne la comblera pas — il commentera élégamment votre angle mort.

Corollaire pratique : activer UEBA sur les sources pertinentes (Entra ID, journaux d'audit Azure Activity, sessions RDP via les événements de sécurité) est un prérequis, pas une option. Sur les environnements où UEBA n'est pas provisionné, la moitié des prompts de corrélation comportementale retourne des tables vides.

Hunting proactif : créer des règles de détection avec l'aide de l'IA

Le passage du hunting opportuniste à la détection industrialisée est l'étape où le gain devient structurel plutôt qu'anecdotique.

Du hunt exploratoire à la règle analytique

Le workflow qui fonctionne en production tient en quatre temps. Premièrement, formuler l'hypothèse en langage naturel adossée à une technique ATT&CK : « Hypothèse : un attaquant utilise T1550.002 (Pass-the-Hash) dans notre environnement. Génère une requête KQL de hunting sur DeviceLogonEvents et IdentityLogonEvents pour détecter les authentifications NTLM de type réseau vers plusieurs hôtes depuis une même source en moins de 10 minutes ». Deuxièmement, exécuter et mesurer le volume brut. Troisièmement, demander explicitement la réduction du bruit : « Cette requête retourne 3 400 résultats sur 7 jours, majoritairement des comptes de service et des scanners de vulnérabilité. Propose des exclusions basées sur des patterns de nommage et sur IdentityInfo, et ajoute un seuil dynamique plutôt qu'un seuil fixe ». Quatrièmement, convertir en règle : « Transforme cette requête en règle analytique planifiée Sentinel : fréquence 15 minutes, lookback 1 heure, mapping des entités Account et Host, gravité Medium, tactiques Lateral Movement, avec un regroupement d'alertes par compte source sur 5 heures ».

Cette dernière étape est celle où la valeur se concentre : le mapping d'entités et la configuration du incident grouping sont laborieux dans l'interface, et une règle sans mapping d'entités correct est une règle qui ne s'enrichira jamais dans le graphe d'investigation. Nous avons développé une bibliothèque de prompts alignés sur la matrice ATT&CK dans notre guide dédié au threat hunting avancé avec Copilot Security.

Promptbooks : capitaliser au lieu de réinventer

Un promptbook est une séquence de prompts enchaînés, paramétrée et réutilisable. C'est le mécanisme qui transforme l'expertise d'un analyste senior en actif d'équipe. Les promptbooks à construire en priorité dans un SOC : qualification d'un incident de phishing (extraction d'en-têtes, réputation d'expéditeur, recherche d'autres destinataires, requête de clics via UrlClickEvents), triage d'une alerte d'exfiltration, et revue hebdomadaire des identités à haut score UEBA. Chaque promptbook consommant des SCU de façon prévisible, ils permettent aussi de budgétiser la capacité — un point que les équipes découvrent généralement après le premier dépassement.

Agents et automatisation

L'écosystème s'étend désormais aux agents, capables d'exécuter des tâches de triage de façon autonome sur un périmètre défini. Notre recommandation terrain est prudente : cantonner les agents aux tâches d'enrichissement et de préqualification, jamais aux actions de remédiation (isolation d'hôte, révocation de session, désactivation de compte) tant que le taux de faux positifs de la détection sous-jacente n'est pas mesuré sur au moins soixante jours. Un agent qui isole un contrôleur de domaine sur une détection mal calibrée transforme un faux positif en incident de production.

Limites réelles : faux positifs, hallucinations et validation manuelle obligatoire

Aucun déploiement sérieux ne tient sans une compréhension précise des modes de défaillance. Ils sont au nombre de quatre.

L'hallucination de schéma

C'est la défaillance la plus fréquente et la plus insidieuse. Le modèle génère une requête référençant une colonne plausible mais inexistante — un AccountUpn là où la table expose AccountName et AccountDomain, un DeviceName dans une table qui n'a que Computer. Le symptôme est une erreur d'exécution explicite, donc bénin. Le cas dangereux est la variante silencieuse : une requête syntaxiquement valide dont un where filtre sur un champ dynamic mal typé et retourne zéro ligne. Un résultat vide n'est jamais une preuve d'absence tant que la requête n'a pas été validée sur un jeu de données de contrôle. Règle d'équipe à imposer : toute requête générée est d'abord exécutée sans son filtre le plus restrictif, pour vérifier que le pipeline retourne bien des données.

La confiance excessive dans la narration

Le modèle produit des réponses assertives et bien structurées, y compris quand les données sous-jacentes sont pauvres. Un résumé d'incident qui affirme « aucune activité de mouvement latéral détectée » signifie strictement « aucune alerte de mouvement latéral n'est présente dans les sources interrogées » — ce qui, sur un environnement où les journaux de sécurité des serveurs membres ne sont pas collectés, ne veut rien dire. Cette asymétrie entre le ton de la réponse et sa valeur probante est le principal risque pour un analyste junior.

Les limites de contexte et de fraîcheur

Les réponses sont construites à partir des données récupérées par les plugins au moment du prompt, dans une fenêtre de contexte finie. Sur un incident volumineux comportant des centaines d'alertes et des milliers d'événements, le résumé est nécessairement un échantillonnage. Un incident majeur ne s'investigue pas par prompts successifs : il s'investigue avec des requêtes, Copilot servant à générer ces requêtes et à documenter les conclusions.

Gouvernance, traçabilité et coût

Trois exigences à formaliser avant la mise en production. La traçabilité d'abord : toute requête générée qui devient une règle analytique doit être versionnée en dépôt Git via l'intégration de dépôts Sentinel, avec mention de son origine et de son validateur humain — un artefact de détection non revu par un humain identifié n'a pas sa place en production. La revue des prompts ensuite : les prompts d'équipe contenant des noms d'hôtes, des identifiants internes ou des extraits de configuration relèvent de la même classification que les logs eux-mêmes. Le coût enfin : les SCU se consomment à l'usage, et un promptbook mal calibré exécuté quotidiennement sur un large périmètre épuise une capacité provisionnée plus vite qu'anticipé. Instrumentez la consommation dès la première semaine.

Cas d'usage terrain : investigation d'un mouvement latéral en 20 minutes

Contexte réel, anonymisé : environnement hybride d'environ 4 000 identités, Active Directory sur site synchronisé vers Entra ID, Defender for Endpoint et Defender for Identity déployés, Sentinel en collecte centrale. Déclencheur : une alerte Defender for Identity « Reconnaissance d'énumération d'utilisateurs et d'adresses IP (SMB) » sur un poste utilisateur, gravité Medium — typiquement le genre d'alerte qui reste vingt-quatre heures dans la file.

Déroulé chronométré

• T+0 à T+3 — Cadrage. Résumé d'incident généré dans le portail Defender. Sortie : un poste source, un compte utilisateur standard du service financier, énumération SMB vers 47 hôtes en 4 minutes, mapping T1018 (Remote System Discovery) et T1087 (Account Discovery).
• T+3 à T+7 — Établissement du point d'entrée. Prompt : « Pour l'hôte source de cet incident, génère et exécute une requête KQL retournant tous les processus créés dans les 2 heures précédant l'alerte, avec la ligne de commande complète et le processus parent, en excluant les binaires signés Microsoft du répertoire System32 ». Résultat : un wscript.exe lancé depuis %APPDATA% par outlook.exe, 38 minutes avant l'énumération.
• T+7 à T+11 — Analyse de la charge utile. Le script est extrait puis soumis à Copilot pour désobfuscation. Sortie : un downloader contactant deux domaines, écrivant une DLL dans %PROGRAMDATA% et créant une tâche planifiée de persistance. Deux IOC réseau et un IOC fichier obtenus.
• T+11 à T+15 — Recherche d'extension. Prompt : « Recherche ces trois IOC sur l'ensemble du parc sur les 14 derniers jours dans DeviceNetworkEvents, DeviceFileEvents et DeviceProcessEvents, et retourne les hôtes concernés avec l'horodatage de première occurrence ». Résultat : deux autres postes touchés, dont un antérieur de six jours — le patient zéro n'était pas celui de l'alerte.
• T+15 à T+18 — Corrélation identité. Prompt : « Pour les trois comptes ayant ouvert une session sur ces hôtes, retourne le score UEBA InvestigationPriority sur 14 jours, les appartenances aux groupes privilégiés depuis IdentityInfo, et toute authentification vers un contrôleur de domaine dans IdentityLogonEvents ». Résultat déterminant : l'un des comptes appartient à un groupe disposant de droits de délégation sur un serveur de fichiers.
• T+18 à T+20 — Décision et confinement. Isolation des trois hôtes, révocation des sessions Entra ID des comptes concernés, réinitialisation forcée, et création d'une règle de hunting sur le pattern de persistance identifié.

Vingt minutes entre l'ouverture de l'alerte et le confinement, contre une estimation de 2 à 3 heures pour le même parcours en manuel. La totalité du gain provient de deux facteurs : l'absence de rédaction manuelle de KQL multi-tables, et l'absence de copier-coller d'IOC entre consoles. Aucune conclusion n'a été prise sur la seule foi d'une réponse générée : chaque requête a été relue avant exécution, et l'extension à trois hôtes a été confirmée par consultation directe de la timeline de chaque device. La compréhension fine de ces mécanismes de propagation — délégation Kerberos, réutilisation de secrets, chemins d'attaque vers les groupes privilégiés — reste indispensable, et c'est précisément ce que valide un pentest Active Directory régulier.

Questions fréquentes

Faut-il une licence Microsoft Sentinel spécifique pour utiliser Copilot Security ?

Non, il n'existe pas de licence Sentinel dédiée à Copilot. Microsoft Security Copilot se facture via des SCU (Security Compute Units) provisionnées à l'échelle du tenant, indépendamment de la facturation à l'ingestion de Sentinel. En revanche, le plugin Sentinel n'est fonctionnel que si vous disposez d'un espace de travail Sentinel actif, et les produits qui s'intègrent en tant que plugins doivent être achetés séparément. Prévoyez donc deux lignes budgétaires distinctes : la capacité Copilot d'une part, l'ingestion et la rétention Sentinel d'autre part.

Copilot Security peut-il interroger mes tables personnalisées et mes logs tiers ?

Oui, dès lors que ces données résident dans l'espace de travail Log Analytics associé à Sentinel. Le plugin exécute du KQL sur l'espace de travail, il n'est donc pas limité aux tables Microsoft. La difficulté est ailleurs : le modèle ne connaît pas le schéma de vos tables _CL. Il faut donc lui fournir explicitement les noms de colonnes dans le prompt, ou lui demander d'abord d'exécuter un getschema sur la table concernée avant de générer la requête d'analyse.

Quelle est la différence entre l'expérience intégrée dans Defender XDR et l'expérience autonome ?

L'expérience intégrée s'affiche en panneau contextuel dans le portail Defender et bénéficie d'un ancrage automatique sur l'objet consulté — incident, alerte, appareil, identité. Elle est optimisée pour la vitesse de triage. L'expérience autonome, sur le portail Security Copilot, donne accès à l'ensemble des plugins activés, aux promptbooks, à l'historique de session et aux plugins personnalisés. Règle simple : triage et qualification dans l'expérience intégrée, investigation approfondie et ingénierie de détection dans l'expérience autonome.

Comment limiter les hallucinations sur les requêtes KQL générées ?

Trois mesures cumulatives. Contraindre le prompt en nommant explicitement les tables et en interdisant l'invention de colonnes. Valider systématiquement toute requête en l'exécutant d'abord sans son filtre le plus restrictif, afin de confirmer que le pipeline retourne des données. Et interdire par politique interne le passage direct d'une requête générée vers une règle analytique de production sans relecture par un ingénieur détection identifié, avec versionnement en dépôt Git.

Un analyste N1 peut-il investiguer seul avec Copilot Security ?

Il peut aller nettement plus loin qu'avant, mais pas conclure seul. Copilot élève le plancher de compétence en supprimant la barrière du KQL, ce qui permet à un N1 de mener les étapes de collecte et de contextualisation. La décision de qualification — vrai positif, faux positif, escalade — exige de savoir distinguer une absence de données d'une absence de menace, jugement que le modèle ne fournit pas et que sa formulation assertive peut au contraire masquer. Le modèle opérationnel qui fonctionne : N1 assisté pour la collecte, N2 pour la décision.