Scans de sécurité : vérifier l'autorisation avant les tests

Le périmètre d’un scan de sécurité définit les systèmes et les services qu’une évaluation peut tester, les techniques qu’elle peut employer et les conditions à respecter. Un nom d’hôte découvert ou une adresse IP issue d’une résolution DNS indique une relation technique. Avant d’envoyer des requêtes de test, déterminez qui peut autoriser cette évaluation précise, quelles exclusions s’appliquent et qui peut la suspendre si la destination ou l’autorisation change.

Cette distinction prend tout son sens lorsque le nom de votre entreprise apparaît dans le trafic reçu par le serveur de quelqu’un d’autre. Un outil peut découvrir une relation réelle tout en délimitant mal les tests que vous avez commandés.

Le 13 septembre, l’opérateur bénévole d’un serveur de temps a signalé un trafic de tests de sécurité inattendu comportant un nom d’hôte Tesla et des identifiants associés à Assetnote. Selon son hypothèse, un alias DNS pointant vers un ensemble partagé de serveurs de temps pouvait expliquer ce ciblage. L’opérateur précisait explicitement qu’il s’agissait d’une supposition. La page indique désormais qu’Assetnote l’a contacté et que le problème est résolu. Elle n’établit ni une cause confirmée par le fournisseur ni une compromission réussie.

Pour votre équipe, la question dépasse ce témoignage : quelles preuves permettent de considérer un actif découvert comme une cible de scan autorisée ? La méthode ci-dessous est notre recommandation opérationnelle, illustrée par des actifs fictifs. Elle sert à examiner vos propres pratiques, sans porter de jugement sur les dispositifs internes de ces deux entreprises.

Que couvre réellement le périmètre d’un scan de sécurité ?

Une évaluation doit délimiter le service testé et les actions autorisées à son encontre. Une simple liste d’actifs ne précise pas quelles opérations sont permises.

Prenons une entreprise fictive, Example Works, dont l’application est accessible sur app.example.com. Votre équipe applicative peut maîtriser le code et la configuration propre à ses clients, tandis qu’un prestataire exploite le réseau sous-jacent. L’autorisation de tester l’application ne dit pas si l’évaluation peut sonder des services sans rapport à la même adresse, tester l’environnement d’un autre client ou employer des techniques susceptibles de perturber le service.

Rédigez le périmètre pour que l’évaluateur puisse répondre à trois questions sans rien supposer : quelle cible peut recevoir du trafic, quelles actions y sont permises et quel événement impose une suspension ? Précisez l’environnement et l’identité du compte concernés. Une application en production et sa copie de préproduction peuvent avoir des responsables, des données et des contraintes d’exploitation différents, même si leurs noms se ressemblent.

La section 6.5 du NIST SP 800-115 décrit une planification des évaluations qui couvre les systèmes autorisés et exclus, les activités de test, la logistique, le traitement des données et les procédures en cas d’incident. Elle traite aussi du consentement des tiers et de l’autorité habilitée à permettre la reprise des tests interrompus. Il s’agit de recommandations publiées en 2008, et non d’une nouvelle obligation pour 2026.

Appliquez ce principe avec un niveau de détail adapté à la mission. Un examen applicatif restreint peut se contenter d’un descriptif court. Une évaluation récurrente sur une infrastructure évolutive exige un dossier tenu à jour et un moyen de vérifier les changements avant l’exécution. Dans les deux cas, quelqu’un doit pouvoir expliquer pourquoi la prochaine requête respecte le périmètre.

Où peut mener un nom d’hôte découvert ?

Un nom d’hôte peut désigner un service que vous utilisez sans établir votre maîtrise de tout ce qui se trouve derrière. Conservez les éléments de découverte, mais examinez la relation avec le service avant d’autoriser des tests actifs.

Les exemples suivants sont fictifs. Ils présentent des questions à résoudre, pas des règles qui approuvent ou rejettent automatiquement une cible.

Une infrastructure partagée n’est pas automatiquement exclue des tests. Vous pouvez disposer d’une autorisation valable pour évaluer votre application en passant par les serveurs périphériques d’un prestataire. Le périmètre est dépassé lorsque cette autorisation s’étend implicitement à d’autres clients, ports ou services au seul motif qu’ils partagent une adresse.

Les consignes du NTP Pool à l’intention des fournisseurs décrivent les modalités prévues pour les produits qui utilisent le pool comme service de temps par défaut, notamment des noms d’hôte dédiés aux fournisseurs. Ces dispositions concernent l’utilisation d’un service de temps. À elles seules, elles n’autorisent pas les tests de sécurité sur les machines des bénévoles qui le fournissent.

Conservez les dépendances exclues dans votre inventaire. Votre équipe de sécurité peut encore avoir besoin d’examiner leur configuration, de discuter des garanties avec le fournisseur ou de suivre leur remplacement. Retirer un service des tests actifs ne doit pas faire disparaître la dépendance de l’entreprise à ce service.

Que consigner avant d’activer les tests ?

Conservez une fiche d’autorisation succincte à côté de l’inventaire des actifs. Associez chaque actif aux preuves d’autorisation, aux contraintes de test et au responsable de l’évaluation.

Nous proposons les champs suivants. Adaptez-les à votre mission plutôt que de les traiter comme un formulaire de conformité :

• Identité du service : nom d’hôte, environnement et identifiant du client, du compte ou de la ressource concernés.
• Responsables : responsable métier, véritable opérateur et responsable de l’évaluation.
• Éléments de découverte : comment vous avez trouvé l’actif et quelle relation ces éléments établissent.
• Preuves d’autorisation : mission approuvée, politique applicable du prestataire ou accord spécifique, avec leurs limites.
• Travaux autorisés : catégories de techniques, exclusions, comptes permis et attentes concernant le traitement des données.
• Conditions de validité : période ou circonstances couvertes, et changements nécessitant un réexamen.
• Référence d’exécution : configuration de l’outil de scan ou tâche d’évaluation qui applique le périmètre approuvé.
• Contact pour la suspension : personne capable d’arrêter les travaux et personne habilitée à autoriser leur reprise.

N’exigez pas un nouvel e-mail d’autorisation pour chaque fiche. La politique publiée par un prestataire peut déjà permettre certains tests sous des conditions précises. Par exemple, la politique d’AWS relative aux tests d’intrusion distingue les évaluations de l’infrastructure propre aux clients, lorsqu’elles sont permises, des tests visant l’infrastructure ou les services d’AWS eux-mêmes. Le service concerné et les conditions comptent ; une référence générale à un fournisseur cloud ne suffit pas.

Utilisez des états explicites pour éviter que la découverte ne débouche discrètement sur l’exécution. Nous suggérons découvert, en attente de vérification ; vérifié, non autorisé pour cette évaluation ; autorisé sous conditions ; et suspendu dans l’attente d’un réexamen. Nous proposons ces états pour votre processus ; ils ne sont pas intégrés à Kit.

Pour l’environnement d’assistance fictif d’Example Works, la fiche pourrait rester à l’état vérifié mais non autorisé pendant que le responsable examine la politique du fournisseur. La relation est confirmée et l’inventaire reste utile. L’évaluation active n’a simplement pas encore de fondement pour l’inclure. C’est une issue normale, pas une formalité en retard dont il faudrait se débarrasser en cliquant sur un bouton d’approbation.

Comment faire respecter l’autorisation pendant un scan ?

L’évaluation en cours doit conserver les limites du service approuvé. Examinez comment vos outils transforment les noms d’hôte, les redirections et les nouvelles découvertes en tâches exécutables.

Commencez par le passage de l’inventaire à l’outil de scan. Si vous approuvez un nom d’hôte applicatif, vérifiez si l’étape suivante teste cette application ou étend la tâche aux adresses obtenues par résolution. Convertir un nom d’hôte en adresse peut être nécessaire pour établir une connexion. En déduire une autorisation pour tous les services à cette adresse constitue une autre décision.

Posez la même question pour les redirections et l’exploration automatisée. Un lien vers la page de connexion d’un fournisseur peut apporter une information utile à l’inventaire sans étendre l’évaluation à ce fournisseur. Déterminez si l’outil s’arrête, consigne la destination pour examen ou poursuit les tests en vertu d’une autorisation qui la couvre déjà. Rendez ce comportement visible pour la personne qui approuve l’exécution.

Les changements d’infrastructure appellent un réexamen proportionné. Une instance de remplacement au sein du même compte autorisé et du même périmètre de service peut être déjà couverte. Une nouvelle destination extérieure à ce périmètre exige une décision. N’imposez pas une approbation manuelle à chaque changement d’adresse courant ; définissez les conditions d’identité et de propriété qui doivent rester remplies.

Les tâches en attente méritent une vérification à part. Retirer une cible du prochain export de l’inventaire ne démontre pas ce qu’il advient des tâches déjà planifiées ou en cours. Vérifiez comment vos outils d’évaluation annulent les tâches en attente, gèrent les nouvelles tentatives et appliquent les exclusions dans les différents processus d’exécution. Ces questions relèvent du fonctionnement et de la configuration de l’outil de scan. Un document de périmètre ne fournit pas ces garanties.

Conservez la version du périmètre utilisée pour chaque exécution et suffisamment de traces pour rattacher une requête signalée à son évaluation. Restreignez l’accès aux échantillons sensibles. L’objectif est de pouvoir répondre plus tard à une question précise : quel service approuvé cette tâche pensait-elle tester, et sur quelle autorisation s’appuyait-elle ? Une capture de la configuration actuelle ne peut pas expliquer une requête envoyée avec les paramètres de la veille.

Comment un signalement d’erreur de cible doit-il arrêter les tests ?

Prévoyez un chemin direct entre les signalements de trafic d’évaluation indésirable et une personne capable de le suspendre. Votre équipe doit vérifier la cible même si l’expéditeur ne signale aucune vulnérabilité ouvrant droit à une prime.

Un contact dédié aux signalements de vulnérabilités permet de vous joindre. La section 5.5 de la RFC 9116 précise que la présence ou l’absence de security.txt n’implique aucune autorisation de test. Distinguez le moyen de contact de la politique d’autorisation et veillez à ce que chacun reste compréhensible.

Pour l’équipe qui commande l’évaluation, nous recommandons la séquence suivante :

1. Suspendez les travaux concernés. Identifiez assez précisément l’évaluation ou la cible pour arrêter le trafic signalé pendant l’enquête.
2. Conservez un échantillon minimal. Demandez les horodatages et les identifiants de requête pertinents. Évitez de diffuser des corps de requête sensibles ou des identifiants d’accès dans des notifications largement partagées.
3. Trouvez le responsable de l’évaluation. Reliez le signalement à la personne qui a commandé la tâche et peut en modifier le périmètre.
4. Vérifiez la destination. Comparez l’identité du service, le véritable opérateur et les preuves d’autorisation à la tâche exécutée.
5. Corrigez l’exécution autant que les fiches. Rectifiez la cible ou l’exclusion et traitez les requêtes en attente, les nouvelles tentatives et les planifications récurrentes.
6. Vérifiez l’arrêt. Consultez les traces d’exécution pour confirmer que le trafic concerné a cessé. Si nécessaire, demandez à l’opérateur à l’origine du signalement si ses observations le confirment.
7. Répondez pour clore le signalement. Expliquez ce qui a été suspendu ou corrigé, et ne reprenez que les travaux dont l’autorisation est établie.

N’annoncez pas de cause avant de l’avoir vérifiée. Une première réponse utile peut accuser réception du signalement, identifier le responsable de l’enquête et préciser que l’évaluation concernée est suspendue. Une réponse ultérieure distinguera les faits confirmés des incertitudes restantes.

Ce travail est lié à la coordination d’une vulnérabilité entre plusieurs fournisseurs, mais intervient en amont. Ici, la priorité est d’établir la destination légitime du trafic que vous avez vous-même commandé. L’étude d’une éventuelle vulnérabilité peut se poursuivre dans un périmètre approprié, défini séparément.

Comment tester les limites sans sonder de systèmes publics ?

Organisez un exercice sur table avec des fiches d’inventaire fictives et une file de test sans accès réseau. Vous cherchez à observer les décisions et les suspensions avant de faire intervenir de véritables destinations externes.

Dans cet exercice, confiez à un collègue le rôle d’évaluateur et à un autre celui de responsable du service. Faites-les travailler à partir des fiches réellement utilisées par votre équipe. Ne comblez pas oralement les lacunes : relevez les endroits où ils doivent inventer une réponse.

Changez l’opérateur. Partez d’une application fictive approuvée, puis modifiez sa fiche pour indiquer un environnement client hébergé par un fournisseur. Vérifiez si l’autorisation existante couvre cette relation. L’exercice est réussi si l’équipe peut démontrer l’autorisation applicable ou mettre la nouvelle cible en attente d’examen.

Retirez une tâche en attente. Placez une cible fictive dans la file de test, puis retirez son autorisation. Vérifiez les tâches en attente et les nouvelles tentatives, ainsi que la prochaine découverte planifiée. Consignez le mécanisme qui empêche l’exécution des travaux retirés.

Quittez l’application approuvée. Introduisez une redirection fictive vers un autre nom d’hôte d’exemple. Demandez ce que l’évaluateur fait ensuite et où il consigne cette décision. Les limites de la mission doivent déterminer la réponse, quelle que soit la personne qui surveille les tests.

Recevez la réclamation d’un opérateur. Envoyez en interne un exemple de signalement avec un horodatage et un identifiant de requête fictifs. Vérifiez si l’équipe destinataire peut trouver le responsable de l’évaluation, suspendre les bons travaux et fournir une réponse claire sans divulguer d’informations sensibles.

Transformez les échecs en corrections précises : un responsable manquant, une exclusion qui ne couvre pas les nouvelles tentatives ou un formulaire qui envoie la réclamation dans la mauvaise file. Rejouez ensuite le scénario concerné. Réussir signifie démontrer une réponse à ces cas, pas prouver que toute erreur de ciblage possible a été éliminée.

Quelles questions prêtent à confusion sur l’autorisation des scans ?

Une relation technique, des coordonnées de contact et une autorisation répondent à des questions différentes. Rappelez clairement ces distinctions lorsqu’une personne demande d’élargir un scan.

Un CNAME place-t-il la destination dans le périmètre ?

Il établit une relation DNS. Il ne précise pas qui exploite la destination ni quels tests votre mission y autorise. Examinez l’identité du service et l’autorisation applicable avant d’étendre les tests actifs. Un accord existant et valable peut couvrir la destination ; l’alias seul n’établit pas cet accord.

Une politique de divulgation publique autorise-t-elle tous les tests ?

Lisez son périmètre et ses conditions réels. Une invitation à transmettre des signalements est utile, mais les dispositions publiées peuvent limiter les actifs, les comptes, les techniques ou le traitement des données. Adressez les questions sur les limites ambiguës au contact du programme avant tout test actif. Notre guide de configuration du programme explique comment publier ces limites dans Kit.

Chaque prestataire doit-il approuver chaque évaluation individuellement ?

Il n’existe pas de procédure d’approbation universelle adaptée à tous les prestataires. Consultez la politique actuelle pour le service concerné et les travaux envisagés. Certains tests sont couverts par des conditions publiées ; d’autres nécessitent un accord distinct. Conservez les éléments qui fondent votre décision pour éviter au prochain évaluateur de devoir les reconstituer à partir de la page d’accueil générale d’un fournisseur.

Comment Kit facilite-t-il la définition du périmètre et les signalements ?

Votre équipe a besoin d’une politique publique lisible et d’un espace fiable pour traiter les questions qu’elle suscite. L’outil de scan a également besoin de ses propres mécanismes d’exécution, correctement mis en œuvre.

Le portail du programme de divulgation des vulnérabilités (VDP) de Kit publie les cibles incluses, les catégories hors périmètre, les types de vulnérabilités exclus et le texte de la politique de divulgation. Il peut afficher le texte de votre sphère de sécurité (Safe Harbor) et permettre aux chercheurs de copier le périmètre au format Markdown. Utilisez ces pages pour expliquer les limites du service autorisé et indiquer où poser les questions en cas de doute.

Le portail des chercheurs offre un moyen de déposer et de suivre les rapports. Donnez aux personnes qui traitent ces rapports un moyen de joindre le responsable de toute évaluation commandée par votre entreprise. Un rapport sur du trafic indésirable doit parvenir à quelqu’un qui peut en rechercher la source et coordonner une suspension.

Publier un périmètre dans Kit ne vérifie pas la propriété de l’infrastructure, ne confère aucune permission sur un tiers, ne configure pas votre outil de scan et n’annule pas ses tâches en attente. Les paramètres de périmètre ne rejettent pas non plus automatiquement les rapports qui en dépassent les limites publiées. Ces décisions relèvent toujours des personnes et des outils concernés.

Avant votre prochaine évaluation, reliez le périmètre publié, la fiche d’autorisation, la configuration d’exécution et le contact chargé de la suspension. Vérifiez un changement de cible fictif tout au long de ce processus. Le résultat attendu est simple : votre équipe sait expliquer pourquoi un test peut être exécuté et sait l’arrêter lorsque cette explication ne tient plus.