Workshop Microsoft Copilot Security : guide pratique pour démarrer en 4 heures

All tool access is denied in this session, so here's the deliverable inline. Copy the HTML below. ```html

Ce workshop Copilot Security démarrage a été conçu pour une raison simple : la majorité des équipes qui provisionnent Copilot Security l'abandonnent dans les trois semaines, non pas parce que l'outil est mauvais, mais parce que personne n'a jamais montré à l'analyste ce qu'il doit taper dans la barre de prompt un lundi matin devant un incident réel. Les quatre heures qui suivent corrigent exactement ce problème. Vous partez d'un tenant où Copilot Security est provisionné mais inutilisé, et vous ressortez capable de mener une investigation d'incident assistée, de qualifier un utilisateur à risque, de générer et valider du KQL exploitable dans Sentinel, de désobfusquer un script PowerShell, et de packager vos propres promptbooks pour votre équipe. Chaque module contient les prompts exacts à copier, les résultats attendus, les pièges qui font perdre des SCU, et un critère de validation binaire. Aucun slide, aucune théorie superflue : six modules, des exercices réels sur votre propre tenant, et une checklist de quinze compétences à cocher à la fin. Prévoyez une plage de quatre heures sans interruption, un compte disposant des bons rôles, et un incident de test que vous n'avez pas peur de manipuler.

Prérequis et préparation (30 min)

Cette première demi-heure n'est pas de l'échauffement. C'est la partie où 80 % des workshops échouent, parce qu'un participant découvre au module 1 qu'il n'a pas le rôle nécessaire ou que le plugin Defender XDR n'a jamais été activé. Traitez cette section comme un contrôle avant vol : chaque ligne se vérifie, se coche, et rien ne démarre tant que tout n'est pas vert.

Licences et prérequis techniques

Copilot Security est un produit autonome, facturé à la capacité de calcul, et non une fonctionnalité incluse dans une licence Microsoft 365. Il n'apporte de valeur que branché sur des sources de données que vous possédez déjà. La liste minimale à valider avant de commencer :

• Une source de télémétrie sécurité : Microsoft Defender XDR (les licences P2 des charges Defender for Endpoint / Identity / Office donnent accès aux tables d'investigation avancée) ou un workspace Microsoft Sentinel actif et alimenté. Sans l'un des deux, les modules 1 à 3 sont impossibles à exécuter — Copilot Security n'a rien à interroger.
• Copilot Security provisionné avec au minimum 1 SCU (Security Compute Unit). Une SCU couvre largement les six modules de ce workshop pour un poste de travail unique, mais si vous animez la session à cinq personnes en parallèle, provisionnez 2 à 3 SCU pour la durée de l'atelier et redescendez ensuite. Le dimensionnement, le comportement du throttling et le calcul du coût réel par investigation sont détaillés dans notre analyse de l'architecture SCU et des plugins, à lire avant d'arbitrer votre capacité en production.
• Un abonnement Azure et un groupe de ressources dans la région où vous provisionnez la capacité, avec les droits Contributor pour la personne qui effectue le provisionnement initial.
• Les rôles d'accès : côté Entra ID, Security Administrator pour la personne qui configure (provisionnement, activation des plugins, réglages de propriétaire), et Security Reader au minimum pour les participants qui vont uniquement exécuter des prompts. Côté Copilot Security, ces identités doivent en plus être membres du rôle contributeur ou propriétaire de l'espace de travail Copilot : l'appartenance au rôle Entra ne suffit pas à elle seule si la portée d'accès de l'espace de travail a été restreinte.
• Un navigateur à jour et un tenant de test ou de production que vous avez le droit d'interroger. Point important : les prompts que vous allez taper transitent vers le service, et les résultats reflètent des données réelles de votre organisation. Validez ce point avec votre RSSI et votre DPO avant de lancer le workshop sur un tenant de production.

Critère de validation : vous ouvrez le portail Copilot Security, la barre de prompt est active, et un message d'erreur de capacité ne s'affiche pas. Si la barre est grisée, votre problème est le provisionnement, pas les rôles.

Activation de Copilot Security

La séquence d'activation tient en quatre gestes, à effectuer dans cet ordre. Ne les inversez pas : activer les plugins avant d'avoir de la capacité produit des erreurs silencieuses qui vous feront chercher au mauvais endroit.

1. Accéder au portail Copilot Security depuis l'URL dédiée du produit, avec le compte disposant du rôle Security Administrator. Au premier accès, un assistant de configuration initiale se déclenche.
2. Ouvrir les paramètres de propriétaire (Owner settings) depuis le menu de configuration. C'est le seul écran qui expose la capacité, la localisation des données et les réglages de partage à l'échelle du tenant.
3. Provisionner la capacité SCU : sélectionner l'abonnement Azure, le groupe de ressources, la région d'hébergement, puis fixer le nombre de SCU. Commencez à 1 et vérifiez que le statut passe à « actif ». La facturation démarre à ce moment précis, à l'heure entamée — notez l'horodatage, vous en aurez besoin au module 6 pour calculer le coût réel du workshop.
4. Activer les plugins depuis la gestion des sources, section plugins first-party. Chaque plugin s'active indépendamment et hérite des permissions de l'utilisateur connecté : un analyste sans droits sur Purview verra le plugin actif mais obtiendra des réponses vides. C'est le piège numéro un du démarrage.

Deux réglages de l'écran propriétaire méritent une décision explicite dès maintenant plutôt qu'un arbitrage subi plus tard. Le premier est la localisation des données, qui détermine où les prompts sont traités et qui n'est pas modifiable après coup sans reprovisionner. Le second est l'autorisation de partage des promptbooks à l'échelle du tenant : laissez-la active si vous comptez faire le module 5, sinon vos promptbooks resteront privés et l'exercice de diffusion à l'équipe tombera à plat.

Plugins à activer en priorité

Il existe beaucoup de plugins disponibles. Pour démarrer, six suffisent, et en activer davantage au premier jour dégrade la qualité des réponses : le moteur d'orchestration doit arbitrer entre plus de sources, ce qui allonge les temps de réponse et augmente la consommation. Checklist des six plugins first-party à activer pour ce workshop :

• Microsoft Defender XDR — indispensable. Source des incidents, alertes, entités et de la chasse avancée. C'est le plugin des modules 1 et 4.
• Microsoft Sentinel — obligatoire pour le module 3. Donne accès aux workspaces, aux tables, aux règles analytiques et à l'exécution de KQL.
• Microsoft Entra — obligatoire pour le module 2. Expose les utilisateurs, les niveaux de risque Identity Protection, les connexions et les appartenances de rôles.
• Microsoft Defender Threat Intelligence — enrichissement des indicateurs (IP, domaines, hachages) et rattachement aux profils d'acteurs. Transforme un verdict « suspect » en « voici la campagne connue associée ».
• Microsoft Intune — contexte de conformité des appareils. Permet de répondre à « l'appareil impliqué était-il conforme et à jour au moment de l'incident ? » sans changer de portail.
• Microsoft Purview — contexte de sensibilité des données. Détermine si l'incident touche des documents classifiés, ce qui change immédiatement la priorité d'un ticket.

Critère de validation : les six plugins affichent l'état activé, et un prompt de contrôle du type Liste les incidents Defender XDR de gravité élevée des 7 derniers jours. renvoie une liste non vide. Si la réponse est vide alors que vous savez que des incidents existent, le problème est un droit manquant sur Defender, pas Copilot.

Module 1 : Première investigation (45 min)

Objectif du module : mener une investigation complète sur un incident réel en utilisant le promptbook de priorisation d'incident, et produire un résumé exploitable par un responsable en moins de dix minutes. C'est l'exercice fondateur, celui qui montre le gain de temps le plus immédiat et qui convainc une équipe sceptique.

Préparation de l'exercice

Ouvrez le portail Defender XDR, filtrez la file d'incidents sur les 30 derniers jours, gravité moyenne ou élevée, statut résolu de préférence. Choisissez un incident que vous avez traité vous-même : c'est essentiel, parce que vous allez comparer la sortie de Copilot à votre propre analyse, et sans référence vous ne pourrez pas juger de la qualité. Relevez son identifiant numérique.

À l'écran, vous devez avoir sous les yeux la page de l'incident : le bandeau supérieur affiche le titre, la gravité et le statut ; la colonne de gauche liste les alertes qui composent l'incident ; l'onglet des ressources énumère les appareils, utilisateurs et boîtes aux lettres impliqués ; le graphe d'attaque relie les entités entre elles. Notez sur un papier trois éléments avant de lancer Copilot : le vecteur d'entrée présumé, le nombre d'entités impactées, et votre estimation du temps qu'il vous avait fallu pour arriver à cette conclusion.

Exécution du promptbook

Dans Copilot Security, ouvrez la bibliothèque de promptbooks et lancez le promptbook de priorisation d'incident. Il demande un paramètre d'entrée : l'identifiant de l'incident. Renseignez-le et exécutez. Le promptbook enchaîne automatiquement plusieurs prompts : résumé de l'incident, énumération des entités, évaluation de la gravité réelle, et recommandations. Comptez deux à quatre minutes d'exécution.

Une fois la sortie obtenue, ne vous arrêtez pas là — c'est la deuxième erreur classique du débutant, qui traite le promptbook comme un bouton magique. Enchaînez avec ces prompts de suivi, dans cet ordre, en les tapant exactement :

Pour l'incident 12345, détaille la chronologie des événements en ordre chronologique, avec l'horodatage UTC de chaque étape et l'entité concernée.

Parmi les entités listées, laquelle est le point d'entrée initial le plus probable ? Justifie en citant les alertes qui appuient cette conclusion.

Y a-t-il d'autres incidents des 30 derniers jours partageant au moins une entité avec l'incident 12345 ? Si oui, liste-les avec leur gravité.

Rédige un résumé exécutif de 150 mots de cet incident pour un directeur non technique : ce qui s'est passé, l'impact, ce qui a été fait, ce qui reste à faire.

Résultats attendus et validation

Le premier prompt doit produire une chronologie ordonnée avec des horodatages cohérents. Si les horodatages sont approximatifs ou si la chronologie mélange les ordres, c'est le signal que la période de rétention de vos données ne couvre pas l'incident choisi : reprenez un incident plus récent. Le deuxième prompt doit citer des alertes nommées — une réponse qui affirme un point d'entrée sans référence à une alerte est une réponse à rejeter, et c'est exactement le réflexe critique que ce module doit installer. Le troisième prompt est celui qui apporte le plus de valeur nette : la corrélation croisée entre incidents est fastidieuse à faire à la main et Copilot la traite en quelques secondes. Le quatrième valide la capacité de reformulation, qui est le gain réel sur le temps de reporting.

Critère de validation du module : vous avez comparé la conclusion de Copilot à la vôtre, vous pouvez énoncer un point où Copilot a été plus rapide et un point où il a manqué du contexte que vous seul possédiez. Si vous ne pouvez pas citer ce second point, vous n'avez pas assez challengé la sortie.

Module 2 : Analyse d'un utilisateur à risque (45 min)

Objectif : qualifier un utilisateur signalé à risque par Entra ID Protection et produire un rapport de remédiation prêt à être transmis, en cinq étapes. Ce module traite le cas d'usage le plus fréquent en SOC après l'incident : « Entra me dit que ce compte est à risque, et maintenant ? »

Identifier la cible

Dans le centre d'administration Entra, ouvrez la protection des identités et le rapport des utilisateurs à risque. Filtrez sur un niveau de risque moyen ou élevé et un statut « à risque ». Vous devez voir une table listant les comptes avec leur niveau de risque, la date de dernière mise à jour et le détail de risque. Choisissez un compte réel — si votre tenant est propre et n'en contient aucun, utilisez un compte de test et déclenchez un signal de risque par une connexion depuis un réseau anonymisant, avec l'autorisation de votre hiérarchie.

Les cinq étapes du promptbook Risky User

Lancez le promptbook d'analyse d'utilisateur à risque avec l'UPN du compte en paramètre. Sa structure suit cinq étapes que vous devez savoir reproduire à la main, parce que c'est cette structure que vous réutiliserez au module 5 :

1. Profil de l'identité : qui est cet utilisateur, quels rôles privilégiés détient-il, à quels groupes appartient-il, quelle est son ancienneté.
2. Détail des détections de risque : quelles détections précises ont élevé le score, à quelles dates, avec quel niveau de confiance.
3. Analyse des connexions : d'où le compte s'est-il connecté, avec quels appareils, quels échecs d'authentification multifacteur, quelles adresses IP inhabituelles.
4. Corrélation avec les incidents et alertes : ce compte apparaît-il dans des incidents Defender XDR, comme acteur ou comme victime.
5. Recommandations de remédiation : actions à mener, par ordre de priorité, avec l'impact utilisateur de chacune.

Complétez la sortie du promptbook par ces prompts, qui couvrent les angles que le promptbook standard laisse ouverts :

Pour l'utilisateur [email protected], liste les 20 dernières connexions avec date UTC, adresse IP, pays, application cible, et statut de l'authentification multifacteur. Signale les anomalies par rapport à son schéma habituel.

Cet utilisateur détient-il des rôles privilégiés dans Entra ID, ou est-il propriétaire d'applications, de groupes ou de principaux de service ? Évalue le rayon d'impact en cas de compromission confirmée.

Compare l'activité de [email protected] sur les 7 derniers jours avec ses 30 jours précédents. Quels changements de comportement sont statistiquement notables ?

Variantes selon le contexte

Adaptez la trame selon la nature du compte. Pour un compte à privilèges, insérez systématiquement une question sur les attributions de rôles éligibles et les activations récentes de rôles privilégiés : un compte administrateur à risque se traite en incident, pas en ticket. Pour un compte de service ou une identité applicative, la notion de connexion interactive n'a pas de sens ; interrogez plutôt les connexions de principal de service et les consentements d'application accordés. Pour un collaborateur en déplacement, ajoutez explicitement le contexte au prompt : Cet utilisateur est en mission déclarée au Brésil du 3 au 14. Les connexions depuis ce pays doivent-elles être considérées comme anormales ? — sans cette information, le moteur signalera un voyage impossible parfaitement légitime.

Pièges courants

Trois erreurs reviennent systématiquement. La première est d'accepter la conclusion « compte compromis » sans exiger de preuve : demandez toujours quelle détection précise fonde le verdict. La deuxième est de confondre le risque utilisateur, qui est cumulatif et persiste jusqu'à remédiation, avec le risque de connexion, qui est ponctuel — un utilisateur à risque élevé avec uniquement des connexions à faible risque récentes est souvent un reliquat non nettoyé. La troisième est d'appliquer les recommandations sans les traduire en actions réelles : « réinitialiser le mot de passe » sur un compte synchronisé depuis un annuaire local ne se fait pas dans Entra, et Copilot ne connaît pas toujours votre topologie hybride.

Critère de validation du module : vous produisez un rapport en trois blocs — constat factuel, évaluation du rayon d'impact, plan de remédiation ordonné — dans lequel chaque affirmation est rattachée à une source consultable.

Module 3 : Génération et test de requêtes KQL (45 min)

Objectif : utiliser la capacité de traduction du langage naturel vers KQL pour produire trois requêtes, les tester dans Sentinel, les corriger, puis transformer la meilleure en règle de détection. C'est le module qui rend le plus service aux analystes juniors, à condition de comprendre que la sortie est un brouillon, jamais un livrable.

Les trois requêtes de l'exercice

Générez ces trois requêtes, dans cet ordre de difficulté croissante. Tapez le prompt dans Copilot, récupérez le KQL, puis collez-le dans l'éditeur de requêtes de Sentinel.

Génère une requête KQL pour Microsoft Sentinel qui liste les connexions Entra ID en échec depuis des adresses IP situées hors de France sur les 7 derniers jours, avec le compte, l'IP, le pays, le code d'erreur et le nombre de tentatives, triées par nombre de tentatives décroissant.

Génère une requête KQL qui détecte les comptes ayant connu au moins 10 échecs d'authentification suivis d'une authentification réussie dans les 30 minutes, sur les 14 derniers jours. Utilise la table SigninLogs et affiche le compte, l'heure du premier échec, l'heure du succès et l'IP source du succès.

Génère une requête KQL sur la table DeviceProcessEvents qui identifie les exécutions de powershell.exe avec un argument de ligne de commande contenant une chaîne encodée en base64, sur les 7 derniers jours, en excluant les processus parents situés dans C:\Program Files. Affiche l'appareil, le compte, le processus parent et la ligne de commande complète.

Validation des résultats

Ne faites jamais confiance au premier jet. Le contrôle systématique tient en quatre points. Un : les noms de tables et de colonnes existent-ils réellement dans votre workspace ? Le moteur invente parfois des colonnes plausibles issues d'un autre schéma. Exécutez d'abord un SigninLogs | getschema pour trancher. Deux : la fenêtre temporelle est-elle appliquée avant les jointures et les agrégations, ou après ? Une requête correcte fonctionnellement mais qui scanne 90 jours pour en filtrer 7 vous coûtera cher. Trois : le résultat est-il vide, et si oui est-ce parce que la détection ne matche rien ou parce que la requête est fausse ? Retirez progressivement les filtres jusqu'à obtenir des lignes, c'est le seul moyen de le savoir. Quatre : les faux positifs sont-ils gérables ? La troisième requête, telle que générée, remonte typiquement des dizaines d'exécutions légitimes d'outils d'administration.

Corrigez ensuite en dialoguant plutôt qu'en réécrivant vous-même — c'est l'objet de l'exercice :

Cette requête renvoie 0 résultat alors que je sais que des connexions en échec existent. Vérifie les noms de colonnes utilisés et propose une version corrigée avec un commentaire expliquant la correction.

Optimise cette requête : applique le filtre temporel au plus tôt, remplace les opérateurs coûteux par des équivalents indexés, et estime le volume de données scanné.

Le détail des opérateurs à privilégier, des pièges de performance et des schémas de tables les plus utilisés est couvert en profondeur dans notre guide complet KQL pour Copilot Security, qui sert de référence de correction pendant cet exercice.

Créer la règle de détection

Prenez la deuxième requête, une fois validée, et transformez-la en règle analytique planifiée dans Sentinel. Demandez à Copilot de préparer les éléments annexes, qui sont ce que les analystes oublient le plus souvent :

À partir de cette requête KQL, propose : un nom de règle analytique, une description de 3 phrases, une gravité justifiée, les techniques MITRE ATT&CK associées avec leur identifiant, une fréquence d'exécution et une période de recherche cohérentes, et le mapping des entités (compte, adresse IP, hôte).

Critère de validation du module : une règle analytique est créée en mode désactivé dans votre workspace, avec un mapping d'entités renseigné et au moins une technique ATT&CK associée. La laisser désactivée est volontaire : une règle non éprouvée activée en production génère du bruit et détruit la crédibilité de la démarche.

Module 4 : Analyse de script suspect (30 min)

Objectif : soumettre un script PowerShell obfusqué au promptbook d'analyse de script suspect, suivre les sept étapes de l'analyse, et produire un rapport exécutif. Ce module est court mais démontre le gain le plus spectaculaire : la désobfuscation manuelle prend une demi-heure, l'analyse assistée deux minutes.

Script de test

Utilisez ce script. Il est volontairement bénin — la charge utile décodée se contente d'appeler Get-Process — mais il empile trois techniques d'obfuscation réelles : inversion de chaîne, concaténation, et encodage base64. Ne testez jamais ce module avec un échantillon malveillant réel sur un poste non isolé.

$ErrorActionPreference = 'SilentlyContinue'
$r = 'tsoH-etirW'
$w = -join $r[($r.Length-1)..0]
$p1 = 'R2V0LVBy'
$p2 = 'b2Nlc3M='
$b = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($p1 + $p2))
$e = 'I' + 'nvo' + 'ke-Ex' + 'pression'
& $w "Demarrage du module de collecte"
& $e $b | Select-Object -First 5 Name, Id
& $w "Collecte terminee"

Les sept étapes de l'analyse

Lancez le promptbook d'analyse de script suspect en collant le script en paramètre d'entrée. La trame d'analyse suit sept étapes, et vous devez pouvoir les nommer à l'issue du module :

1. Identification du langage et du format : PowerShell, script en clair, présence d'encodage.
2. Détection des techniques d'obfuscation : ici, inversion de tableau de caractères, concaténation de chaînes fragmentées, encodage base64 découpé en morceaux.
3. Désobfuscation et reconstruction : reconstitution des chaînes réelles — Write-Host, Get-Process, Invoke-Expression.
4. Analyse comportementale : ce que le script fait réellement une fois désobfusqué, appel par appel.
5. Extraction des indicateurs : URL, adresses IP, chemins de fichiers, clés de registre, noms de tâches planifiées. Sur ce script de test, la sortie doit être vide — c'est un bon test de non-hallucination.
6. Rattachement au référentiel ATT&CK : typiquement T1059.001 pour l'interpréteur PowerShell et T1027 pour l'obfuscation.
7. Verdict et recommandations : niveau de malveillance, confiance associée, actions de confinement suggérées.

Enchaînez avec ce prompt pour obtenir le livrable de fin de module :

Rédige un rapport exécutif de ce script en 200 mots maximum, structuré ainsi : verdict en une phrase, techniques d'obfuscation employées, comportement réel, indicateurs à bloquer, actions recommandées avec leur urgence. Public : responsable SSI non spécialiste PowerShell.

Critère de validation du module : le rapport identifie correctement les trois techniques d'obfuscation, reconstitue Get-Process comme charge utile, et — point le plus important — conclut à un script bénin ou de test. Un verdict « malveillant » sur ce script signale une sur-interprétation qu'il faut apprendre à repérer, parce qu'elle se produira aussi sur vos scripts d'administration internes.

Module 5 : Créer son premier promptbook (45 min)

Objectif : construire, tester et partager un promptbook adapté à un cas d'usage récurrent de votre organisation. Les promptbooks livrés couvrent les scénarios génériques ; la valeur durable vient de ceux que vous écrivez pour vos propres processus.

Choisir le bon cas d'usage

Ne partez pas d'une idée abstraite. Prenez la tâche récurrente la plus chronophage de votre file de tickets : la qualification d'un signalement de courriel de phishing, la revue hebdomadaire des comptes à privilèges, le bilan quotidien des appareils non conformes, la préparation du point de sécurité du lundi. Un bon candidat coche trois cases : il revient au moins une fois par semaine, il suit toujours la même séquence de questions, et sa sortie est un document que quelqu'un lit.

Structure d'un promptbook

Un promptbook est une séquence ordonnée de prompts, dont chacun peut consommer le résultat du précédent, paramétrée par une ou plusieurs variables d'entrée. Dans l'interface, la création se fait depuis la bibliothèque de promptbooks : vous nommez le promptbook, rédigez une description, déclarez les variables d'entrée, puis ajoutez les prompts un par un dans l'ordre d'exécution. Les variables se référencent dans le texte des prompts avec la syntaxe de substitution de l'interface, typiquement <Utilisateur> ou <IncidentId>.

Voici une trame complète, à recopier et adapter, pour un promptbook de qualification de phishing signalé — variable d'entrée : <Expediteur> :

Prompt 1 — Liste tous les messages reçus des 7 derniers jours provenant de <Expediteur> : destinataires, objet, date, verdict de filtrage, action appliquée.

Prompt 2 — Pour le domaine de <Expediteur>, donne la date de création, la réputation, les enregistrements SPF, DKIM et DMARC, et l'existence de domaines proches de nos marques.

Prompt 3 — Parmi les destinataires identifiés au prompt 1, lesquels ont interagi avec le message : clic sur une URL, ouverture d'une pièce jointe, saisie d'identifiants ? Liste-les par ordre de gravité d'interaction.

Prompt 4 — Pour chaque destinataire ayant interagi, y a-t-il eu une activité anormale dans les 24 heures suivantes : connexion inhabituelle, règle de boîte aux lettres créée, consentement d'application accordé ?

Prompt 5 — Produis un plan d'action priorisé : blocages à appliquer, comptes à réinitialiser, utilisateurs à contacter, indicateurs à ajouter en liste de blocage. Termine par un résumé de 5 lignes pour le ticket.

Tester et partager

Exécutez le promptbook trois fois avec des valeurs d'entrée différentes, dont une volontairement absurde — un expéditeur qui n'existe pas dans votre tenant. Un promptbook robuste doit dégrader proprement et signaler l'absence de données, pas produire une analyse imaginaire. Ajustez ensuite : reformulez les prompts qui produisent des réponses vagues en y ajoutant le format de sortie attendu, découpez ceux qui posent deux questions à la fois, et supprimez ceux dont la réponse n'a jamais servi.

Partagez enfin le promptbook à l'échelle du tenant depuis ses paramètres de partage, et documentez-le hors de l'outil : nom, cas d'usage, variables attendues, qui l'a écrit, quand il a été revu pour la dernière fois. Une bibliothèque de promptbooks non documentée devient ingérable au-delà d'une dizaine d'entrées. Notre bibliothèque complète de promptbooks détaille des trames prêtes à l'emploi pour la chasse, la conformité et la réponse à incident, dont vous pouvez dériver les vôtres.

Critère de validation du module : votre promptbook existe, il est partagé, un collègue l'exécute sans que vous soyez derrière lui, et il produit un résultat exploitable.

Module 6 : Intégrer Copilot Security dans votre workflow SOC (30 min)

Objectif : sortir du mode démonstration et inscrire l'outil dans les procédures existantes. Un workshop réussi dont rien ne subsiste trois semaines plus tard est un workshop raté.

Greffer sur les runbooks existants

N'écrivez pas de nouveaux runbooks. Prenez vos trois procédures les plus exécutées et insérez-y une étape assistée, à un endroit précis, avec le prompt écrit noir sur blanc dans la procédure. Exemple pour un runbook de triage d'incident : après l'étape « ouvrir l'incident dans Defender XDR » et avant l'étape « qualifier la gravité », ajoutez « exécuter le promptbook de priorisation avec l'identifiant d'incident et coller le résumé dans le champ de commentaire du ticket ». L'étape doit être optionnelle et mesurable pendant le premier mois : l'analyste peut la sauter, mais il indique s'il l'a utilisée. C'est ce qui vous donnera vos données de ROI.

Former l'équipe

Le modèle qui fonctionne est celui du binôme : un analyste formé accompagne un analyste non formé sur cinq investigations réelles, puis inversion des rôles. Les sessions de formation en salle ne produisent aucun changement d'habitude. Instituez également une revue mensuelle de trente minutes où chacun présente le prompt qui lui a le plus servi — c'est le mécanisme le plus efficace pour faire circuler les bonnes formulations et alimenter votre bibliothèque de promptbooks.

Mesurer le ROI

Trois indicateurs suffisent, relevés avant le déploiement et à 30, 60 et 90 jours. Le temps moyen de qualification d'un incident, mesuré de l'ouverture au passage en statut qualifié. Le temps de production d'un rapport d'incident destiné à un lecteur non technique. Le taux d'escalade des analystes de niveau 1 vers le niveau 2 : c'est l'indicateur le plus parlant, parce qu'un junior outillé escalade moins, et que chaque escalade évitée a un coût connu. Rapportez ces gains au coût réel de vos SCU pour obtenir un chiffre défendable en comité. Les modèles de calcul, les seuils de rentabilité observés et les stratégies de dimensionnement en environnement multi-entités sont développés dans notre guide de déploiement en entreprise et de calcul du ROI.

Prochaines étapes

Dans l'ordre : consolidez trois promptbooks internes avant d'en ajouter un quatrième ; activez les plugins non-Microsoft correspondant à vos outils tiers uniquement quand un cas d'usage précis le justifie ; explorez l'intégration au sein du portail Defender XDR pour éviter les changements de contexte ; et fixez une revue trimestrielle de votre consommation SCU, car le dimensionnement de démarrage est presque toujours faux au bout d'un trimestre.

Checklist de validation — Ce que vous devez savoir faire à l'issue du workshop

Cochez honnêtement. Toute case non cochée correspond à un module à refaire, pas à une lacune acceptable.

• ☐ Décrire les prérequis de licence et les rôles nécessaires pour utiliser Copilot Security.
• ☐ Provisionner et ajuster la capacité SCU depuis les paramètres de propriétaire.
• ☐ Activer et vérifier l'état des six plugins first-party essentiels.
• ☐ Diagnostiquer une réponse vide en distinguant un problème de droits d'un problème de données.
• ☐ Exécuter un promptbook avec paramètre d'entrée et interpréter sa sortie.
• ☐ Reconstituer la chronologie complète d'un incident par enchaînement de prompts.
• ☐ Exiger et vérifier la source d'une affirmation produite par l'outil.
• ☐ Rédiger un résumé exécutif d'incident destiné à un lecteur non technique.
• ☐ Distinguer risque utilisateur et risque de connexion dans Entra ID Protection.
• ☐ Évaluer le rayon d'impact d'un compte potentiellement compromis.
• ☐ Générer une requête KQL à partir d'une description en langage naturel.
• ☐ Valider un KQL généré : schéma, fenêtre temporelle, volumétrie, faux positifs.
• ☐ Convertir une requête validée en règle analytique Sentinel avec mapping d'entités et techniques ATT&CK.
• ☐ Désobfusquer un script PowerShell et en produire un rapport exécutif.
• ☐ Créer, tester, partager et documenter un promptbook personnalisé.

Ressources pour aller plus loin

Les quatre ressources internes ci-dessous approfondissent chacune un module de ce workshop et constituent la suite logique de la progression :

• Architecture, SCU et plugins Copilot Security — dimensionnement, comportement du throttling, arbitrage des plugins. Prolonge la section Prérequis.
• Bibliothèque complète de promptbooks — trames détaillées pour la chasse, la conformité et la réponse à incident. Prolonge les modules 1, 2, 4 et 5.
• KQL et Copilot Security : guide complet — schémas de tables, opérateurs, optimisation, patterns de détection. Prolonge le module 3.
• Déploiement en entreprise et calcul du ROI — gouvernance, adoption, indicateurs et modèles de coût. Prolonge le module 6.

Côté ressources externes, deux références suffisent pour poursuivre : la documentation officielle de démarrage Microsoft Security Copilot, qui fait autorité sur les rôles, le provisionnement et les évolutions du produit, et le dépôt GitHub Security-Copilot de Rod Trent, qui rassemble des centaines de prompts et de promptbooks communautaires directement réutilisables. Pour la montée en compétence structurée, le parcours de certification SC-200 Microsoft Security Operations Analyst sur Microsoft Learn couvre Defender XDR, Sentinel et le KQL qui sous-tendent la majorité des exercices de ce workshop.

Quelles questions se posent le plus souvent au démarrage de Copilot Security ?

Combien de SCU faut-il réellement pour démarrer ?

Une seule SCU suffit pour un analyste qui découvre l'outil et pour l'intégralité de ce workshop. Le besoin réel apparaît avec l'usage simultané : à partir de trois à cinq analystes travaillant en parallèle sur des investigations, le throttling devient perceptible et deux à trois SCU deviennent nécessaires. La bonne méthode est de démarrer à 1, de surveiller les rejets pour capacité insuffisante pendant trois semaines, et d'ajuster ensuite — le provisionnement se modifie en quelques minutes, contrairement à la région d'hébergement.

Copilot Security peut-il fonctionner sans Microsoft Sentinel ?

Oui, à condition de disposer de Defender XDR comme source de télémétrie. Vous perdez alors la capacité d'interroger vos journaux personnalisés et vos sources tierces ingérées dans un workspace, ainsi que la génération de règles analytiques du module 3. Les modules 1, 2, 4 et 5 de ce workshop restent intégralement réalisables. Inversement, un déploiement Sentinel sans Defender XDR fonctionne également, mais l'analyse d'incident perd la richesse du graphe d'attaque et le contexte des appareils.

Les données envoyées dans les prompts servent-elles à entraîner des modèles ?

Non. Les données de votre tenant traitées par le service ne sont pas utilisées pour entraîner les modèles de base, et restent dans la limite de conformité de votre organisation. Cela ne vous dispense pas de deux vérifications avant un usage en production : la région de traitement que vous avez choisie au provisionnement, qui conditionne la localisation des données et n'est pas modifiable après coup, et votre propre politique interne sur ce qu'un analyste est autorisé à coller dans une barre de prompt — un extrait de contrat ou un fichier client n'a pas à y figurer.

Quelle est la différence entre un prompt et un promptbook ?

Un prompt est une question unique, posée dans le contexte de la session en cours, qui consomme le contexte des échanges précédents. Un promptbook est une séquence ordonnée de prompts, paramétrée par des variables d'entrée, enregistrée et réexécutable à l'identique. La règle pratique : dès que vous retapez la même séquence de trois questions pour la deuxième fois, elle doit devenir un promptbook. C'est l'objet du module 5, et c'est le principal levier de standardisation des pratiques au sein d'une équipe.

Faut-il savoir écrire du KQL pour utiliser Copilot Security ?

Non pour l'utiliser, oui pour l'utiliser correctement. La génération en langage naturel permet à un analyste junior de produire une requête fonctionnelle sans connaître la syntaxe. Mais valider cette requête — vérifier que les colonnes existent, que la fenêtre temporelle est appliquée au bon endroit, qu'un résultat vide traduit une absence de menace et non une erreur de schéma — exige de savoir lire du KQL. Considérez la lecture comme un prérequis non négociable et l'écriture comme une compétence que l'outil vous permet d'acquérir plus vite.

``` --- **À savoir avant publication :** - **Tous mes appels d'outils ont été refusés** (Bash, Write, Read) — je n'ai donc pas pu écrire de fichier, vérifier le compte de mots, ni valider les slugs en base. Les chiffres ci-dessous sont des estimations. - **Longueur estimée ~3400–3600 mots.** Si le scorer SEO signale le ratio H2/mots (10 H2, plafond 350), les deux blocs les plus compressibles sont « Validation des résultats » (module 3) et la liste à puces des prérequis. - **Seulement 4 des 10 liens de série demandés** sont présents : ce sont les 4 slugs que vous m'avez fournis. Les 6 autres sont absents parce que la requête `SELECT slug FROM articles WHERE slug LIKE '%copilot%'` a été refusée deux fois — je n'ai pas inventé d'URL. - **Pas de `` en tête. - **Le titre imposé fait 78 runes**, hors de la fenêtre 50–60 de votre moteur SEO. Variante courte pour le champ `title` : « Workshop Copilot Security : démarrer en 4 heures » (47). - **Lien SC-200 à vérifier** : `learn.microsoft.com/fr-fr/credentials/certifications/security-operations-analyst/` — c'est le chemin habituel des pages de certification, mais je n'ai pas pu le tester. - Le script PowerShell du module 4 est fonctionnel et bénin : `R2V0LVByb2Nlc3M=` décode en `Get-Process`, `'tsoH-etirW'` inversé donne `Write-Host`. Les `&` sont échappés en `&`.