EASM et conformité NIS2 : cartographier sa surface
d'attaque externe

Posez la question fatidique à n'importe quel RSSI : « Combien d'actifs exposez-vous sur Internet ? » Vous obtiendrez un chiffre. Lancez ensuite une vraie découverte d'assets exposés, et ce chiffre sera invariablement faux. Toujours plus grand. Le sous-domaine de campagne marketing oublié, l'API de staging « temporaire » de 2021, le bucket S3 d'un prestataire parti depuis longtemps : voilà votre véritable surface d'attaque externe. Et c'est exactement là que la directive NIS2 vient gentiment vous tapoter l'épaule.

L'EASM (External Attack Surface Management, ou gestion de la surface d'attaque externe) n'est plus un gadget de SOC mature : c'est devenu un prérequis opérationnel pour répondre à l'article 21 NIS2. Dans cet article, on démêle les deux, on parle shadow IT, cartographie des actifs, corrélation CVE, et on regarde concrètement comment relier la contrainte réglementaire à une pratique offensive qui tient la route.

NIS2 en 30 secondes (sans la novlangue de Bruxelles)

La directive (UE) 2022/2555, dite NIS2, élargit massivement le périmètre de son prédécesseur. Là où NIS1 couvrait environ 500 entités en France, NIS2 en concernerait entre 15 000 et 20 000 selon les estimations de l'ANSSI. Autant dire que beaucoup d'organisations qui ne se sentaient pas concernées par la cyber-réglementation vont découvrir qu'elles le sont — les PME en première ligne, souvent par effet de ruissellement via la sous-traitance. Pour le panorama complet de la directive (statuts, obligations, sanctions, calendrier), on renvoie au guide complet de la directive NIS2.

La directive distingue deux catégories : les entités essentielles(énergie, santé, transports, banque, infrastructures numériques…) et les entités importantes (services postaux, gestion des déchets, agroalimentaire, fabrication, fournisseurs numériques…). Différence concrète : les essentielles subissent une supervision proactive, les importantes une supervision a posteriori (en clair, on vient vous voir après l'incident). Côté sanctions, la directive prévoit des amendes pouvant atteindre 10 M€ ou 2 % du chiffre d'affaires mondial pour les entités essentielles.

L'article 21, ou pourquoi vous devez savoir ce que vous exposez

Le cœur technique de NIS2, c'est l'article 21. Il impose aux entités essentielles et importantes des mesures « techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour gérer les risques, selon une approche dite « tous risques ». L'article 21(2) liste dix mesures minimales. Parmi elles, deux nous intéressent particulièrement :

• (a) les politiques d'analyse des risques et de sécurité des systèmes d'information ;
• (i) la sécurité des ressources humaines, les politiques de contrôle d'accès et la gestion des actifs.

Voilà le point de bascule. On ne peut pas conduire une analyse de risques crédible sur un périmètre qu'on ne connaît pas. Et on ne peut pas « gérer ses actifs » si la moitié d'entre eux sont des actifs fantômes que personne n'a inventoriés. L'article 21 ne prononce jamais le mot « EASM », mais sa logique l'impose en filigrane : la cartographie des actifs exposés est le socle de tout le reste.

L'EASM, c'est quoi exactement ?

L'External Attack Surface Management est la discipline qui consiste à découvrir, inventorier et surveiller en continu tout ce que votre organisation expose sur Internet, du point de vue de l'attaquant. Pas depuis votre réseau interne, pas depuis votre CMDB : depuis l'extérieur, comme le ferait quelqu'un qui prépare une intrusion. La nuance est capitale. Si vous découvrez la discipline, on en fait le tour complet dans notre guide qu'est-ce que l'EASM ; ici, on se concentre sur son articulation avec NIS2.

Concrètement, une plateforme EASM enchaîne plusieurs étapes :

1. Découverte : à partir de quelques graines (nom de domaine, marque, plages IP, organisation), elle déroule la pelote — sous-domaines, certificats TLS (Certificate Transparency), enregistrements DNS, ASN, dépendances tierces. C'est aussi ce qui fait remonter les sous-domaines oubliés qui pointent dans le vide, mûrs pour un subdomain takeover.
2. Inventaire et attribution : elle relie chaque actif découvert à votre organisation, et identifie ports ouverts, technologies, services exposés.
3. Corrélation des vulnérabilités : elle confronte les versions détectées aux flux de CVE (typiquement la NVD du NIST) pour faire remonter les expositions connues.
4. Priorisation et surveillance continue : elle hiérarchise par exploitabilité réelle et re-scanne en boucle, parce qu'une surface d'attaque, ça bouge tous les jours.

  GRAINES                DECOUVERTE               CORRELATION            VERDICT
 +----------+          +--------------+         +-----------+        +-----------+
 | domaine  |          | sous-domaines|         |  versions |        |  expose   |
 | marque   |  ----->  | certs TLS    | ------> |    vs     | -----> | priorise  |
 | plages IP|          | DNS / ASN    |         | flux CVE  |        | par risque|
 +----------+          | ports/techno |         |  (NVD)    |        +-----+-----+
                       +--------------+         +-----------+              |
        ^                                                                  |
        +---------------  surveillance continue (re-scan)  <---------------+

Inventaire déclaratif vs réalité exposée : trouvez la différence

Le grand malentendu, c'est de croire qu'un fichier Excel d'actifs ou une CMDB constituent un inventaire de surface d'attaque. Ils décrivent ce que vous pensez exposer. L'EASM, lui, mesure ce que vous exposez vraiment. Entre les deux, il y a toujours un delta — et c'est précisément dans ce delta que les attaquants vivent leur meilleure vie.

Vous voulez « trouver la différence » entre votre inventaire et votre surface réelle ? Bonne nouvelle : ce ne sont pas la même image. Mauvaise nouvelle : l'écart contient probablement votre prochain incident.

De la découverte au verdict : le piège des CVE

Découvrir des actifs et lister des CVE, c'est la partie facile. Le vrai problème commence après : un scanner classique vous noie sous des centaines de « vulnérabilités critiques » dont une bonne partie n'est pas exploitable dans votre contexte (service non atteignable, fonctionnalité désactivée, faux positif sur une bannière de version). Résultat : vos équipes s'épuisent à patcher du bruit pendant que la vraie faille exploitable dort tranquillement.

C'est exactement la frontière entre détecter et démontrer. Si le sujet vous parle, on l'a creusé dans pentest vs scan de vulnérabilité : un scan dit « c'est peut-être vulnérable », un pentest prouve que ça l'est. L'EASM moderne emprunte cette logique offensive pour la passer à l'échelle, en validant l'exploitabilité réelle plutôt que de cracher une liste brute de CVE.

EASM et NIS2 : la jonction concrète

Mettons les choses bout à bout. L'article 21 vous demande une analyse de risques (a) et une gestion des actifs (i), proportionnées à votre exposition. Une démarche EASM sérieuse alimente directement ces obligations :

• Cartographie des actifs exposés à jour et auditable — vous savez quoi inventorier dans votre gestion des actifs.
• Analyse de risques fondée sur le réel — l'exposition mesurée nourrit l'évaluation de proportionnalité exigée par la directive.
• Surveillance continue — NIS2 raisonne en posture permanente, pas en audit annuel ; l'EASM colle à cette temporalité.
• Traçabilité — en cas de contrôle ANSSI, montrer un processus de découverte et de remédiation documenté vaut bien mieux qu'un Excel daté de l'an dernier.

Pour les composants applicatifs, l'EASM se complète avec une démarche d'AppSec sur le code lui-même. On a comparé les approches dans SAST, DAST, IAST et IA : l'EASM cartographie le périmètre, l'AppSec creuse l'intérieur des applications. Les deux sont complémentaires, pas concurrents.

Et own2pwn dans tout ça ?

On ne va pas faire semblant : on a construit notre plateforme exactement autour de cette logique. La plateforme EASM d'own2pwn fait de la découverte automatique des assets exposés, corrèle les CVE via le flux NVD, et — c'est notre marque de fabrique — valide l'exploitabilité de façon IA-native plutôt que de vous balancer une liste indigeste. Le tout en surveillance continue, et hébergé en France pour ceux que la souveraineté concerne (spoiler : avec NIS2, ça vous concerne). On explique pourquoi ce choix pèse dans un dossier de conformité dans notre analyse de l' EASM souverain hébergé en France.

Pour aller plus loin sur le code applicatif, notre brique SecAI (AppSec IA) ajoute un SAST piloté par l'IA et un agent de pentest autonome. Et quand il faut la rigueur d'un humain expert sur un périmètre critique, nos services de pentest web blackbox et whitebox prennent le relais. La conformité NIS2 n'est pas une case à cocher : c'est une posture, et la posture commence par voir clair.

La bonne nouvelle, c'est que se mettre en conformité NIS2 n'oblige pas à réinventer la sécurité : ça oblige à enfin regarder ce qu'on expose. Et ça, ça commence par un scan honnête de votre surface d'attaque externe. Le plus tôt sera le mieux — avant que quelqu'un d'autre ne le fasse à votre place.