Pentest d’entreprise : quand le réaliser et que doit-il réellement couvrir ?

Un test d’intrusion est souvent demandé au moment où il faut « faire la sécurité » : avant une mise en ligne, après un incident, parce qu’un client l’exige, ou parce qu’un scan a renvoyé une liste longue. La demande est légitime. Elle est mal posée si l’on attend du pentest qu’il remplace un inventaire, une revue de configuration ou un travail de correction.

Le pentest répond à une question précise. À partir d’un périmètre autorisé, que peut obtenir quelqu’un qui cherche vraiment, et quelle est la conséquence métier ? Le reste — la liste brute de vulnérabilités, la politique, le suivi des correctifs — relève d’autres exercices.

Pentest, scan de vulnérabilités, audit : ce n’est pas la même chose

Un scan interroge des services et des versions, puis signale ce qui ressemble à une vulnérabilité connue. Il est utile pour couvrir large et pour répéter l’exercice souvent. Il ne montre pas si le défaut est exploitable dans votre contexte, ni ce qu’un enchaînement permet d’atteindre.

Un audit compare un existant à un référentiel ou à vos propres règles : comptes, sauvegardes, journalisation, séparation des environnements, droits. Il peut se faire en grande partie sur documents et sur configuration. Il ne tente pas d’entrer.

Un pentest tente. Dans le cadre écrit, un testeur cherche un chemin : une faille applicative, un mauvais cloisonnement, un secret exposé, un enchaînement de droits trop larges. Le résultat qui compte n’est pas le nombre de lignes. C’est le scénario, la preuve, et l’impact si personne ne corrige.

Confondre les trois produit de mauvaises attentes. Un scan « rouge » n’est pas un pentest raté. Un pentest qui ne trouve qu’un défaut médian n’a pas forcément été trop court : il a peut-être montré que le chemin facile n’existe pas. Encore faut-il que le périmètre ait été le bon.

Quand un pentest devient pertinent

Le test vaut le coût quand le résultat peut changer une décision ou un ordre de correction. Quelques moments reviennent :

• avant une mise en production exposée, une fois que l’application tient debout et que le périmètre ne change plus tous les jours ;
• après un changement important : nouvelle brique exposée, refonte d’authentification, ouverture à des partenaires, fusion d’environnements ;
• quand le système est déjà joignable depuis l’extérieur, ou depuis un réseau où des comptes à privilèges circulent ;
• quand un contrat, un client ou un assureur demande une preuve d’un test réalisé sur un périmètre nommé, à une date nommée ;
• de façon périodique sur les systèmes dont l’arrêt ou la fuite coûte cher, à un rythme lié à cette criticité, pas à un calendrier générique.

Il est peu utile très en amont, sur une maquette qui sera réécrite, ou juste après un scan dont personne n’a traité les points évidents. Corriger d’abord ce qu’un outil montre déjà, puis tester l’enchaînement, donne un meilleur usage du temps de test.

Le sujet plus large — quoi protéger, dans quel ordre, au-delà d’un seul test — est celui de sécuriser applications et infrastructure.

Définir le périmètre

Sans périmètre, il n’y a pas de test. Il y a une exploration, et personne ne peut dire si elle a couvert ce qui compte.

Applications web et API

Les parcours authentifiés, pas seulement la page d’accueil. Les rôles réels. Les fonctions qui modifient une donnée ou déclenchent un paiement, un envoi, une validation. Les API telles qu’elles sont appelées, y compris celles qu’aucune interface ne montre plus mais qui répondent encore.

Infrastructure

Côté externe : ce qui est joignable depuis Internet, y compris les environnements de test qu’on a oubliés ouverts. Côté interne : ce qu’un poste ou un compte déjà dans le réseau peut atteindre. Les deux ne se substituent pas. Une application saine derrière un réseau plat reste un problème. Un réseau soigné devant une application qui fait confiance à tout ce qu’elle reçoit aussi.

Sur site

Un passage physique ou sur le réseau local se justifie quand le scénario redouté commence par un accès aux locaux, à une prise, ou à un équipement. Ce n’est pas un supplément automatique d’un pentest applicatif. C’est une mission dont les contraintes — horaires, accompagnement, zones interdites — se décident à part.

Le périmètre se ferme aussi par ce qui est exclu. Un partenaire dont on n’a pas l’autorisation. Un système industriel dont l’arrêt n’est pas acceptable. La production elle-même, si l’on a choisi de ne pas l’attaquer. L’exclusion doit être aussi explicite que l’inclusion.

Rules of Engagement

Les règles d’engagement tiennent sur quelques pages, et elles doivent être signées par quelqu’un qui a le droit d’engager l’organisation :

• l’autorisation explicite, le périmètre, les dates ;
• les horaires, et ce qui est interdit en heures ouvrées ;
• les techniques autorisées et celles qui ne le sont pas : déni de service, ingénierie sociale, phishing des employés, exploitation qui modifierait des données réelles ;
• les comptes de test fournis, et les comptes qu’il est interdit de cibler ;
• les contacts joignables pendant le test, y compris un chemin si quelque chose casse ;
• la façon dont on s’arrête si un incident réel se déclare en même temps ;
• ce qu’on fait des données éventuellement vues : conservation, chiffrement, destruction en fin de mission.

Ces règles protègent les deux côtés. Le testeur sait jusqu’où aller. L’organisation sait ce qui a été permis, et peut distinguer une alerte du test d’une alerte qui n’en est pas une.

Production ou environnement dédié ?

Tester en production montre la configuration réelle, les données telles qu’elles sont exposées, et les oublis qu’une copie propre n’a pas. Le risque est de perturber un service, de verrouiller des comptes, ou de toucher une donnée qu’il ne fallait pas toucher.

Tester sur un environnement dédié limite ce risque. Il ne vaut que si cet environnement ressemble encore à la production : mêmes versions, mêmes rôles, mêmes intégrations qui comptent, données réalistes mais non réelles. Une copie vieille de six mois, ou un bac à sable sans la brique exposée, rassure sans conclure.

Le compromis fréquent est un partage. Vérifications non destructives sur la production — configuration, en-têtes, authentification, exposition — et tentatives plus poussées sur une cible dédiée dont on a contrôlé l’écart. Le rapport doit dire où chaque constat a été obtenu. Un défaut vu seulement sur la copie n’a pas le même statut qu’un défaut vu en production, tant que l’écart n’est pas expliqué.

L’exploitation courante de ces environnements — qui déploie, qui surveille, qui sépare les accès — relève du cloud et de l’infogérance autant que du test. Un pentest ne répare pas un déploiement que personne ne sait reproduire.

Ce que le rapport doit permettre de faire

Un rapport qui énumère des failles sans chemin de correction se range. Le destinataire doit pouvoir, pour chaque constat qui compte :

• comprendre le scénario en une lecture, sans défaire un outil ;
• voir la preuve, assez précise pour reproduire le correctif, pas assez pour servir de mode d’emploi public ;
• juger l’impact dans son contexte, pas seulement une note générique ;
• savoir quelle correction ferme le chemin, et lesquelles ne font que gêner une étape ;
• ordonner le travail : ce qui est exposé maintenant, ce qui attend une évolution, ce qui est un durcissement utile mais secondaire.

La priorité se discute. Une faille « critique » sur un composant injoignable n’est pas le premier correctif. Une faille moyenne qui ouvre les dossiers clients depuis Internet l’est. Le rapport doit donner les éléments de cet arbitrage, pas le confisquer.

Après le rapport : remédiation et retest

Le test s’arrête au constat. La valeur est dans ce qui change ensuite. Chaque point retenu a un responsable, un délai lié à l’exposition, et une preuve de correction. « On a mis à jour » n’est une preuve que si le chemin testé ne fonctionne plus.

Le retest porte sur les corrections annoncées, pas sur un nouveau périmètre glissé au passage. Il confirme que le scénario est fermé, et il signale si le correctif en a ouvert un autre. Les points non repris restent ouverts : les taire dans la version suivante du rapport donne une impression de progrès qui n’a pas eu lieu.

Entre deux tests, le scan et la revue de configuration reprennent leur rôle. Ils attrapent la dérive courante. Le pentest suivant repart d’un système qui a bougé, au lieu de retrouver les mêmes portes.

Cybersécurité et tests d’intrusion couvrent cette suite : cadrage du test, réalisation, rapport exploitable, puis accompagnement de la correction. Le test sans suite est un document. La suite sans test est une liste d’intentions.

Et la Red Team ?

Une mission Red Team n’est pas un pentest de plus grande taille. Le pentest cherche ce qui est faible dans un périmètre connu, avec la coopération des équipes qui opèrent. La Red Team poursuit un objectif — atteindre une donnée, un processus, un droit — sur une durée plus longue, en mesurant aussi si la détection et la réponse fonctionnent.

Les règles y sont encore plus strictes, parce que les équipes de défense ne sont pas toutes au courant, et parce que le scénario peut traverser plusieurs systèmes. Ce n’est pas le premier exercice d’une organisation qui n’a pas encore traité les résultats d’un scan et d’un pentest ciblé. C’est un exercice utile quand les bases tiennent et que la question devient : est-ce qu’on verrait une attaque qui prend son temps ?

Le bon prochain pas est donc rarement « le plus gros test disponible ». C’est le test dont le périmètre correspond au risque que vous voulez réduire, avec une autorisation claire, et un rapport dont quelqu’un pourra tirer un ordre de correction.