Comment se déroule une mission de test d’intrusion, et ce qui l’encadre

Un périmètre flou produit un rapport flou. Le cadrage fixe par écrit les cibles exactes (domaines, adresses, dépôts, comptes cloud), les rôles et comptes de test à fournir, les environnements concernés et les fenêtres d’intervention.

C’est aussi le moment où nous disons si la prestation demandée est la bonne. Il arrive qu’une mission red team soit prématurée, ou qu’un audit de code apporte plus qu’un test d’intrusion : mieux vaut l’entendre au cadrage qu’à la restitution.

Les tests de sécurité sont des actes encadrés par la loi. L’autorisation écrite précise qui autorise, sur quel périmètre, pendant quelle période, et avec quelles limites. Elle couvre aussi le cas des actifs hébergés chez un tiers, qui demandent souvent un accord distinct.

Les règles d’engagement listent les interdits : pas de déni de service, pas d’action destructive, pas d’exfiltration de données réelles, pas de contournement de protections au-delà du périmètre, et arrêt immédiat sur simple demande d’un contact désigné.

La reconnaissance est largement industrialisée par notre plateforme interne : énumération des sous-domaines, résolution, sondage des services, découverte de contenu et de paramètres, cartographie des technologies. C’est du travail de largeur, qu’une machine fait mieux et plus vite.

L’écart entre la surface découverte et celle que vous pensiez avoir est un résultat en soi. Environnements de recette oubliés, anciennes versions encore en ligne, interfaces d’administration exposées : ces découvertes figurent dans le rapport, même quand elles sortent du périmètre de test : elles sont signalées, jamais sondées.

Deux couches travaillent en parallèle. La couche outillée couvre le connu : vulnérabilités cataloguées, défauts de configuration, composants obsolètes. La couche humaine traite ce qui demande de comprendre votre métier : contrôle d’accès, logique applicative, chaînage de défauts mineurs en impact majeur.

Chaque constat est reproduit avant d’être retenu. Une vulnérabilité non reproductible ne va pas dans le rapport : elle passe en observation, avec ce qui a été vu et pourquoi cela mérite un examen de votre côté.

Toute vulnérabilité critique est signalée immédiatement, sans attendre la fin de la mission.

La synthèse s’adresse à une direction : ce qui est exposé, ce que cela coûterait, ce qu’il faut décider et dans quel ordre. Elle se lit en dix minutes, sans bagage technique.

Le rapport technique s’adresse à ceux qui corrigent : une fiche par vulnérabilité, avec la requête exacte, la réponse obtenue, l’impact démontré, la cause et un correctif applicable. Le classement suit l’exploitabilité réelle dans votre contexte, pas seulement le score CVSS : une faille critique sur un service injoignable passe après une faille moyenne sur votre page de connexion.

La restitution se fait en direct avec les équipes techniques, et séparément avec la direction si vous le souhaitez.

Une correction peut échouer de trois façons : ne pas traiter la cause, ne couvrir qu’un des points d’entrée, ou introduire un nouveau défaut. La passe de vérification rejoue les preuves d’origine et contrôle les variantes voisines.

Elle produit une attestation de correction, utilisable face à un client, un assureur ou un comité de sécurité.