Gestion de la surface d'attaque externe (EASM) avec Microsoft Copilot Security

La surface d'attaque externe d'une organisation de taille intermédiaire dépasse presque toujours l'inventaire que ses équipes croient maintenir : sous-domaines de campagnes marketing oubliées, environnements de préproduction publiés « temporairement », instances SaaS enregistrées sur un domaine d'entreprise par une direction métier, certificats wildcard qui exposent une arborescence entière, adresses IP encore routées après une migration cloud. En 2026, cette dérive n'est plus un sujet d'hygiène : c'est le premier vecteur d'accès initial exploité par les opérateurs de ransomware, qui scannent l'Internet exposé plus vite que la plupart des DSI ne mettent à jour leur CMDB. Microsoft adresse ce problème par deux briques distinctes qu'il faut apprendre à faire travailler ensemble : Microsoft Defender External Attack Surface Management (Defender EASM), qui découvre et cartographie l'exposition depuis l'extérieur, et Microsoft Security Copilot, qui transforme cet inventaire brut en décisions de remédiation priorisées. Cet article détaille l'architecture réelle de cette chaîne, ses prérequis de licence, ses requêtes KQL, ses angles morts, et la façon dont elle se compare aux plateformes EASM tierces déjà déployées dans beaucoup de SOC français.

Defender EASM et Copilot Security : l'alliance découverte + analyse intelligente

La confusion la plus fréquente en avant-vente consiste à présenter Security Copilot comme un scanner. Il ne scanne rien. La découverte externe reste intégralement assurée par Defender EASM, qui est une ressource Azure autonome, provisionnée dans un groupe de ressources, avec sa propre infrastructure de crawl. Copilot Security intervient une couche au-dessus : il interroge, corrèle et restitue. Comprendre cette séparation évite les déceptions de POC.

Ce que fait Defender EASM seul

Defender EASM part de graines (seeds) : quelques domaines racines, blocs IP, numéros d'AS ou contacts WHOIS que vous déclarez comme vôtres. À partir de ces graines, le moteur exécute une découverte récursive qui suit les enregistrements DNS, les certificats TLS, les en-têtes HTTP, les redirections, les données WHOIS et les relations d'hébergement. Chaque itération produit de nouveaux candidats, eux-mêmes réinjectés comme point de départ. C'est ce chaînage transitif — et non un simple scan de plage IP — qui fait remonter les actifs que personne ne cherchait. Les résultats sont classés en groupes de découverte (discovery groups), planifiables, ce qui permet de séparer l'exposition d'une filiale, d'une marque ou d'une entité juridique acquise.

Ce que Copilot Security ajoute réellement

Security Copilot fonctionne sur un modèle de plugins : chaque source de données Microsoft ou tierce expose ses capacités au moteur d'orchestration, qui décide quelles compétences invoquer pour répondre à une question en langage naturel. La documentation officielle détaille ce modèle dans la présentation des plugins Security Copilot. Concrètement, un analyste qui demande « quels actifs découverts cette semaine exposent un service d'administration et portent une vulnérabilité activement exploitée ? » déclenche un plan d'exécution qui interroge l'inventaire EASM, croise le référentiel de vulnérabilités, et restitue une réponse structurée avec justification. Le gain n'est pas cosmétique : il supprime l'étape de traduction entre une intention métier et une requête technique, étape qui monopolisait jusqu'ici les deux ou trois personnes de l'équipe maîtrisant le portail. Pour la logique de consommation sous-jacente, voir notre analyse de l'architecture de Copilot Security.

Inventaire automatique des actifs exposés : domaines, IP, certificats et services

L'inventaire est le produit central de Defender EASM. Sa valeur dépend entièrement de la qualité de la validation humaine appliquée aux candidats découverts : un inventaire non arbitré est un inventaire faux, et un inventaire faux produit des priorisations fausses, y compris quand c'est Copilot qui les formule.

Les types d'actifs et leur graphe de rattachement

Defender EASM manipule sept types d'actifs : domain, host, page, IP block, IP address, ASN et SSL certificate, auxquels s'ajoutent les enregistrements de contact WHOIS utilisés comme pivots. Ces types ne sont pas une taxonomie décorative : ils forment un graphe dont les arêtes portent la raison du rattachement. Un hôte est rattaché parce qu'il partage un certificat, parce qu'il résout vers un bloc IP déclaré, ou parce que son WHOIS partage un e-mail d'enregistrement. Lors d'un arbitrage, c'est cette chaîne de preuve qu'il faut lire, pas seulement le nom de l'actif.

Les certificats TLS, vecteur de découverte le plus productif

Sur le terrain, la source qui fait remonter le plus d'inconnues n'est ni le DNS ni le WHOIS : ce sont les certificats. Les journaux de transparence des certificats publient tous les noms alternatifs (SAN) émis, y compris ceux d'environnements internes exposés par erreur. Un seul certificat multi-SAN émis par une équipe applicative peut révéler une dizaine de sous-domaines de recette. Corollaire opérationnel : un certificat wildcard *.groupe.fr réduit cette visibilité pour l'attaquant, mais il la réduit aussi pour vous, tout en élargissant l'impact d'une compromission de clé privée. Beaucoup d'organisations découvrent cet arbitrage au moment de la première campagne EASM.

Les états d'inventaire et la discipline d'arbitrage

Chaque actif porte un état : Approved Inventory (confirmé vôtre), Candidate (proposé par le moteur, non arbitré), Requires Investigation (signal ambigu) et Dismissed (écarté). La règle que nous imposons en accompagnement est simple : aucun tableau de bord de direction ne doit être construit avant que la file Candidate soit descendue à zéro une première fois. Sinon les métriques d'exposition intègrent des actifs d'hébergeurs mutualisés ou de partenaires, et le premier comité de sécurité qui le remarque disqualifie l'outil pour deux ans.

Prérequis, licences et coût : provisionner les SCU et la ressource Defender EASM

Deux facturations distinctes coexistent, et les confondre fausse tout business case. C'est la question que posent systématiquement les directions financières au deuxième comité de projet.

Les Security Compute Units

Security Copilot se consomme en SCU (Security Compute Units), provisionnées à l'heure via une capacité déclarée dans une région Azure donnée. Le provisionnement est ajustable : vous pouvez augmenter la capacité avant une campagne de triage massive et la redescendre ensuite. Deux points comptent en exploitation. D'abord, la capacité est horaire, donc une session lancée à 23 h 50 consomme sur deux tranches. Ensuite, une requête mal cadrée qui déclenche plusieurs plugins consomme davantage qu'une requête ciblée — l'écart entre un prompt vague et un prompt contraint est significatif à l'échelle d'une équipe. Les modalités de dimensionnement et le calcul de retour sur investissement sont traités dans notre article sur le déploiement en entreprise.

La ressource Defender EASM

Defender EASM se facture séparément, sur un modèle à l'actif et à la journée, après une période d'évaluation permettant de mesurer la taille réelle de son inventaire. C'est un piège classique : une organisation qui déclare des graines trop larges — un bloc IP d'opérateur, un ASN partagé — voit son inventaire exploser et sa facture avec. Commencez par des graines strictement maîtrisées, puis élargissez groupe de découverte par groupe de découverte. Ordre de grandeur constaté : un groupe industriel français multi-marques passe couramment de quelques centaines d'actifs déclarés à plusieurs milliers d'actifs réels dès la première itération.

Identités et rôles

L'accès s'appuie sur Entra ID. Côté Copilot, les rôles Security Administrator et Security Reader gouvernent l'usage et l'administration des plugins ; côté EASM, le RBAC Azure standard s'applique sur la ressource. Point d'attention : Copilot respecte les permissions de l'utilisateur qui pose la question. Un analyste sans droit de lecture sur la ressource EASM obtiendra une réponse incomplète, sans message d'erreur explicite. Ce comportement — souhaitable en matière de cloisonnement — est la première cause de tickets « Copilot ne trouve rien ».

Priorisation des expositions : CVE exploitables vs théoriques

Un inventaire externe de quelques milliers d'actifs génère mécaniquement des centaines d'observations de vulnérabilité. Aucune équipe ne les traite toutes. La question opérationnelle n'est donc pas « quelles vulnérabilités ai-je ? » mais « lesquelles un attaquant utilisera-t-il cette semaine ? ».

Pourquoi le CVSS seul est un mauvais signal de priorisation

Le CVSS mesure une gravité intrinsèque, pas une probabilité d'exploitation. Trier par « CVSS ≥ 9,0 » produit une file où des vulnérabilités jamais exploitées côtoient des failles activement instrumentées, et où une faille de score moyen mais massivement exploitée passe sous le radar. Sur un périmètre externe, ce biais est coûteux : il fait consacrer des semaines à des correctifs sans effet sur le risque réel.

KEV et EPSS : un triage à deux axes

Le triage qui fonctionne combine deux référentiels publics. Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA liste les vulnérabilités dont l'exploitation est constatée : appartenir à ce catalogue est un fait, pas une prédiction. L'EPSS attribue une probabilité d'exploitation à 30 jours, utile pour les CVE absentes du KEV. La règle de tri que nous déployons : présence dans KEV sur un actif exposé à Internet, quel que soit le CVSS, en priorité absolue ; puis EPSS élevé sur service d'authentification ou d'administration ; puis le reste, traité au rythme du cycle de patch. Un service d'accès distant vulnérable et référencé KEV se traite en heures, pas en sprints.

Formuler la requête dans Copilot

La qualité de la réponse dépend de la contrainte imposée au prompt. Un prompt exploitable ressemble à : « Liste les actifs Defender EASM en état Approved Inventory exposant un port d'administration, portant une CVE présente au catalogue KEV, découverts ou modifiés depuis 7 jours ; pour chacun, indique l'actif parent, la raison du rattachement et l'action de remédiation recommandée ; réponds sous forme de liste ordonnée par criticité. » Trois éléments font la différence : la contrainte de périmètre, le format de sortie demandé, et l'obligation de justifier le rattachement — c'est cette justification qui permet à l'analyste de détecter une erreur d'attribution avant d'ouvrir un ticket.

Copilot Security dans Azure Firewall : analyse des politiques et anomalies

L'exposition externe ne se corrige pas seulement en retirant des actifs : elle se corrige aussi en resserrant le filtrage. L'intégration de Security Copilot avec Azure Firewall vise précisément la couche de politique.

Prérequis : les journaux structurés dans Log Analytics

L'intégration exige que le pare-feu émette ses journaux au format structuré (resource-specific) vers un espace de travail Log Analytics. Les journaux hérités au format AzureDiagnostics ne suffisent pas. Les tables à activer sont notamment AZFWNetworkRule, AZFWApplicationRule, AZFWNatRule, AZFWThreatIntel et AZFWIdpsSignature. C'est le prérequis oublié dans la quasi-totalité des premiers essais : Copilot répond « aucune donnée » et l'équipe conclut à un défaut produit alors que le paramétrage de diagnostic n'a jamais été basculé.

Analyse de politique et règles mortes

Une politique Azure Firewall d'entreprise accumule les règles au fil des projets. Copilot permet de poser la question directement : quelles règles n'ont enregistré aucun hit sur 90 jours, quelles règles se recouvrent, quelles règles autorisent une plage source excessivement large vers une destination sensible. Le résultat n'est pas une simple liste : il s'accompagne d'une explication du recouvrement, ce qui rend la revue de politique délégable à un ingénieur réseau qui n'est pas l'auteur des règles. En pratique, la première passe sur une politique de trois à quatre ans identifie systématiquement des règles créées pour une migration terminée depuis longtemps.

Investigation IDPS

Sur le volet IDPS, la valeur porte sur la lecture des signatures déclenchées. Demander « explique la signature IDPS la plus déclenchée sur les 24 dernières heures, indique si la source figure en threat intelligence, et dis-moi si l'actif ciblé apparaît dans mon inventaire EASM » enchaîne trois sources dans une seule interaction. C'est exactement le type de corrélation qui, manuellement, coûte vingt minutes à un analyste de niveau 1 — et qui, faute de temps, n'est simplement pas faite la nuit.

Azure Web Application Firewall (WAF) et Copilot : détection des attaques applicatives

Les actifs les plus exposés d'un inventaire EASM sont presque toujours des applications web. Le WAF est donc le point où la surface d'attaque externe devient du trafic d'attaque observable.

Les catégories de journaux à exploiter

Deux implémentations coexistent. Sur Application Gateway, les événements de filtrage remontent via AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog". Sur Azure Front Door, la catégorie dédiée FrontDoorWebApplicationFirewallLog joue le même rôle pour un WAF positionné en périphérie. Dans les deux cas, les règles proviennent d'ensembles managés dérivés du CRS de l'OWASP, complétés par le jeu de règles de protection contre les bots. Savoir dans quelle table chercher est un prérequis à toute exploitation sérieuse, y compris quand c'est Copilot qui formule la requête.

Du faux positif au réglage de règle managée

Le coût réel d'un WAF n'est pas le blocage d'attaques, c'est le traitement des faux positifs qui cassent une application métier. Le schéma classique : une règle d'injection SQL déclenche sur un champ de formulaire légitime, l'équipe applicative demande une exclusion globale, et la posture se dégrade silencieusement. Copilot change la nature de l'échange en produisant, à partir des journaux, l'identifiant précis de la règle déclenchée, la partie de la requête incriminée et le périmètre minimal d'exclusion — un attribut de requête sur un chemin d'URL donné, plutôt qu'une désactivation de groupe de règles. C'est la différence entre une exclusion chirurgicale et un trou permanent.

Corréler le WAF avec l'inventaire EASM

La corrélation qui a le plus de valeur est la plus simple : les hôtes qui reçoivent du trafic d'attaque sont-ils tous derrière un WAF ? Un actif présent dans l'inventaire EASM, répondant en HTTP, et absent des journaux WAF est soit inutilisé, soit exposé sans filtrage applicatif. Cette question, posée en langage naturel une fois par semaine, remonte régulièrement des applications publiées directement, hors du chemin d'entrée normalisé — typiquement une API métier mise en ligne pour un partenaire et jamais réintégrée à l'architecture cible.

Promptbooks et requêtes KQL : industrialiser l'analyse EASM

Une démonstration repose sur un prompt improvisé ; une exploitation repose sur des prompts figés, versionnés et rejoués à l'identique. C'est la frontière entre un pilote et un service.

Anatomie d'un promptbook EASM

Un promptbook est une séquence ordonnée de prompts exécutée en une fois, éventuellement paramétrée par une entrée. Le promptbook hebdomadaire que nous mettons en place tient en cinq étapes : lister les actifs entrés en inventaire depuis sept jours ; pour chacun, identifier les services exposés ; croiser avec KEV et EPSS ; vérifier la présence d'un WAF en amont ; produire une synthèse ordonnée par criticité avec propriétaire présumé. L'intérêt est la reproductibilité : d'une semaine sur l'autre, la comparaison porte sur les données, pas sur la formulation de l'analyste.

Le KQL reste indispensable

Le langage naturel ne remplace pas KQL, il l'encapsule. Les équipes matures conservent des requêtes de référence — comptage d'actifs par état, évolution du nombre de certificats expirant sous 30 jours, hôtes exposant un service d'administration — et utilisent Copilot pour l'exploration et la restitution. Cette répartition a un avantage de gouvernance : les indicateurs présentés en comité restent calculés par une requête auditable et déterministe, tandis que Copilot sert l'investigation, où la variabilité est acceptable.

Traçabilité des sessions

Chaque interaction s'inscrit dans une session conservant le fil des prompts, les plugins invoqués et les réponses. Pour un SOC soumis à une exigence de preuve — audit ISO 27001, dossier NIS 2, expertise post-incident — cette traçabilité doit être intégrée aux procédures dès le départ : une décision de non-remédiation justifiée par une réponse Copilot doit pouvoir être rejouée. La documentation de référence sur le fonctionnement du produit est disponible sur la page officielle Microsoft Security Copilot.

Flux de travail EASM vers Defender XDR : de la découverte à la remédiation

Découvrir sans remédier ne réduit aucun risque. La chaîne ne crée de valeur que si un actif découvert le lundi devient un ticket assigné le mardi.

L'Exposure Graph comme point de jonction

Dans Microsoft Security Exposure Management, intégré à Defender XDR, les tables ExposureGraphNodes et ExposureGraphEdges exposent en chasse avancée le graphe des actifs et de leurs relations. C'est le point où l'exposition externe rejoint le contexte interne : un hôte découvert de l'extérieur cesse d'être une adresse IP anonyme dès qu'on peut établir qu'il héberge une application authentifiée sur Entra ID, ou qu'il dispose d'un chemin réseau vers un contrôleur de domaine.

Du point d'entrée au chemin d'attaque

C'est cette jonction qui transforme la priorisation. Deux actifs externes portant la même vulnérabilité n'ont pas le même risque : celui qui n'expose qu'un site vitrine statique et celui qui constitue la première marche vers un compte à privilèges se traitent différemment. L'analyse de chemin d'attaque rend cette différence explicite. Les scénarios de rebond depuis un actif exposé vers l'annuaire sont détaillés dans notre méthodologie de pentest Active Directory, et la logique de durcissement associée dans notre article sur la posture Zero Trust avec Defender for Cloud.

Fermer la boucle

La dernière étape est organisationnelle, pas technique. Un actif exposé sans propriétaire identifié ne sera pas corrigé. Le flux qui tient dans la durée associe à chaque actif approuvé un propriétaire applicatif nommé, une date d'entrée en inventaire et une échéance de traitement. Copilot accélère la rédaction — synthèse d'exposition, justification technique, action attendue — mais l'assignation reste un acte de gouvernance. Les déploiements qui échouent sont presque toujours ceux où l'outil a été acheté sans qu'un responsable de la remédiation externe ait été désigné.

Comparaison avec des outils EASM tiers : Shodan, Censys, Bitsight

Beaucoup d'équipes disposent déjà d'un outil de reconnaissance externe. La question n'est pas de remplacer, mais de savoir ce que chaque brique apporte et où elle s'arrête.

Shodan

Shodan indexe les bannières de services exposés à l'échelle d'Internet. Sa force est la profondeur de l'empreinte réseau : versions de services, systèmes industriels, équipements réseau, capture d'écran de services graphiques. Ses limites pour un usage EASM d'entreprise : l'attribution est à votre charge — Shodan vous dit ce qui répond sur une IP, pas si cette IP vous appartient — et la couverture est celle d'un balayage périodique, avec un décalage possible sur les actifs éphémères. C'est un excellent outil de vérification ponctuelle et de veille sur un périmètre connu, pas un moteur de découverte transitive.

Censys

Censys se positionne sur une modélisation plus rigoureuse des hôtes et surtout des certificats, avec une exploitation avancée des journaux de transparence. Pour un travail d'attribution par certificat, sa granularité est un atout réel. Le point de friction reste le même que pour Shodan : la constitution et le maintien du périmètre organisationnel demandent un travail interne, alors que c'est précisément ce que Defender EASM automatise via ses graines et ses groupes de découverte.

Bitsight

Bitsight relève d'une autre catégorie : la notation de risque, y compris tierce partie. Sa valeur est comparative et contractuelle — suivre la posture de ses fournisseurs, objectiver une exigence dans un contrat, présenter une trajectoire à un comité d'audit. Il ne produit pas le niveau de détail technique nécessaire à un analyste qui doit décider s'il coupe un service ce soir. Les deux usages ne sont pas concurrents : un score dégradé est un signal de direction, une CVE référencée KEV sur un service d'administration est une action de SOC.

Quelle combinaison retenir

Pour une organisation déjà investie dans l'écosystème Microsoft, l'argument décisif en faveur de Defender EASM n'est pas la qualité brute de la découverte, sur laquelle les acteurs spécialisés sont solides : c'est le raccordement natif au reste de la chaîne — Defender XDR, Exposure Management, Sentinel, Entra ID — et l'interrogation unifiée par Security Copilot. Un outil tiers produit une liste ; l'intégration produit un chemin d'attaque contextualisé. Conserver un abonnement Shodan ou Censys pour la vérification indépendante reste toutefois une bonne pratique : deux sources de découverte divergentes sont le seul moyen fiable de mesurer l'angle mort de la première.

Limites, angles morts et faux positifs de l'inventaire automatique

Aucun outil EASM ne produit un inventaire complet, et présenter le contraire à un comité de direction est le meilleur moyen de créer un faux sentiment de maîtrise.

Ce que la découverte externe ne voit pas

La découverte s'appuie sur des traces publiques. Un actif sans enregistrement DNS public, sans certificat émis publiquement, joignable uniquement par adresse IP directe et sans lien vers vos graines, a de fortes chances de rester invisible. C'est typiquement le cas de bacs à sable créés par une équipe de développement sur un compte cloud personnel, ou de matériels OT raccordés par une liaison opérateur hors du périmètre déclaré. La parade n'est pas technique : c'est le rapprochement périodique entre l'inventaire EASM, la facturation cloud et les enregistrements des bureaux d'enregistrement de domaines.

Les faux positifs d'attribution

Le mécanisme de découverte transitive produit par construction des rattachements erronés : hébergement mutualisé, prestataire partageant un contact WHOIS, infrastructure CDN partagée. Un actif appartenant à un tiers, s'il est approuvé par erreur, pollue les métriques et peut conduire à signaler une vulnérabilité qui n'est pas la vôtre — avec les conséquences juridiques associées si une action de test est déclenchée. La discipline consiste à ne jamais approuver un actif sans lire la chaîne de rattachement.

Le risque de dérive avec l'assistant

Security Copilot restitue avec une assurance rédactionnelle constante, que la donnée sous-jacente soit fiable ou non. Deux règles s'imposent. D'abord, toute décision irréversible — coupure d'un service, déclaration d'incident, notification à un régulateur — doit être vérifiée dans la source, pas dans la synthèse. Ensuite, un prompt trop large produit une réponse générique qui consomme des SCU sans rien apporter ; la contrainte de périmètre est autant une mesure de qualité qu'une mesure d'économie. L'assistant accélère un analyste compétent ; il ne remplace pas la compétence.

Questions fréquentes

Defender EASM est-il inclus dans Microsoft Security Copilot ?

Non. Ce sont deux produits facturés séparément. Defender EASM est une ressource Azure dont le coût dépend du nombre d'actifs suivis et de la durée de suivi, tandis que Security Copilot se consomme en SCU provisionnées à l'heure. Copilot sait interroger Defender EASM via son plugin dédié, mais il ne fournit aucune capacité de découverte externe par lui-même. Un projet qui budgète l'un en oubliant l'autre se retrouve avec un assistant sans données ou un inventaire sans exploitation.

Comment distinguer une CVE réellement exploitable d'une vulnérabilité théorique ?

Le premier critère est l'appartenance au catalogue KEV de la CISA, qui recense les vulnérabilités dont l'exploitation est effectivement observée. Le second est le score EPSS, qui estime une probabilité d'exploitation à trente jours. Le troisième, souvent négligé, est le contexte d'exposition : la même CVE sur un site vitrine statique et sur une passerelle d'accès distant n'appelle pas le même délai de traitement. Le CVSS seul ne permet aucun de ces trois arbitrages.

Pourquoi Copilot ne renvoie-t-il aucune donnée Azure Firewall ?

Dans la grande majorité des cas, le pare-feu envoie encore ses journaux au format hérité AzureDiagnostics au lieu des tables structurées AZFWNetworkRule, AZFWApplicationRule, AZFWThreatIntel et AZFWIdpsSignature. Vérifiez le paramètre de diagnostic de la ressource, la destination Log Analytics et le fait que l'utilisateur qui interroge dispose bien des droits de lecture sur l'espace de travail concerné — Copilot applique les permissions de l'appelant et ne signale pas explicitement un manque de droits.

Faut-il conserver un outil EASM tiers comme Shodan ou Censys ?

C'est recommandé, mais pour un usage précis : la vérification indépendante. Deux moteurs de découverte n'utilisent pas les mêmes sources ni les mêmes heuristiques d'attribution ; comparer leurs résultats est le seul moyen concret de mesurer l'angle mort du dispositif principal. En revanche, faire cohabiter deux plateformes EASM comme sources de vérité opérationnelles crée des files de traitement concurrentes et une confusion de propriété qui dégrade la remédiation.

Quel volume de SCU prévoir pour un usage EASM régulier ?

Le dimensionnement dépend du nombre d'analystes, de la fréquence des promptbooks et de la largeur des prompts. La démarche fiable consiste à provisionner une capacité minimale, à exécuter pendant deux à quatre semaines les promptbooks réels de l'équipe, puis à ajuster sur la base de la consommation mesurée. Deux leviers réduisent la facture sans perte de valeur : contraindre systématiquement le périmètre temporel et le type d'actif dans les prompts, et réserver l'exploration libre à l'investigation d'incident plutôt qu'au reporting récurrent, ce dernier restant calculé en KQL.