Métier de pentester : missions, livrables et quotidien

Niveau : orientation, débutant à intermédiaire.

Prérequis : notions de réseau, système, Web et risque. Savoir prendre des notes structurées et expliquer un résultat technique est recommandé. L'exercice ne demande aucun test offensif.

Les responsabilités d'un pentester varient selon l'organisation, le secteur, la séniorité, le contrat et le cadre réglementaire. Comprendre ces missions aide à évaluer ce métier, mais ne garantit ni emploi, ni certification, ni maîtrise technique.

La première étape consiste à comprendre la question du commanditaire. Veut-il évaluer une application avant sa mise en production, une exposition externe, un réseau interne ou un scénario précis ? Une formulation vague comme « teste notre sécurité » doit devenir un objectif vérifiable.

Le cadrage précise les adresses IP, les noms de domaine, les applications, les environnements et les comptes inclus. Il liste aussi les exclusions : systèmes tiers, production sensible, fonctions de paiement, tests de déni de service ou données réelles, par exemple. Les règles d'engagement indiquent les dates, les horaires, les sources réseau des testeurs, les contacts, les moyens de communication, les actions interdites et les conditions d'arrêt.

Cette étape réduit les risques opérationnels et juridiques pour le client, le prestataire et les utilisateurs. Une autorisation doit être explicite, attribuée à la bonne entité et valable pour le périmètre réel. Un sous-domaine, une API ou un fournisseur cloud peut appartenir à un tiers. Le pentester ne suppose jamais que l'autorisation s'étend automatiquement.

Le cadrage inclut aussi la logistique : accès VPN, comptes de test, authentification multifacteur, documentation disponible, sauvegardes, supervision et traitement des alertes. Un temps perdu sur un accès non fonctionnel réduit le temps consacré à l'analyse.

Le cadrage décrit par l’ANSSI pour un audit de sécurité et le guide NIST SP 800-115 confirme que la mission commence avant les tests techniques.

Le pentester commence par construire un modèle de la cible dans les limites convenues. Pour une application Web, il identifie les rôles, les parcours, les points d'entrée, les API et les mécanismes de session. Pour une infrastructure, il examine les services, les relations de confiance et les contrôles d'accès accessibles depuis sa position.

Les outils automatisés accélèrent la collecte et signalent des pistes. Ils ne remplacent pas le raisonnement. Un résultat doit être vérifié, replacé dans son contexte et relié à un impact. Une réponse inhabituelle peut être un faux positif. Une faiblesse banale peut, au contraire, devenir sérieuse lorsqu'elle est combinée à une autre.

Le test manuel consiste à formuler une hypothèse, choisir une action proportionnée, observer la réponse et décider de la suite. Les notes doivent permettre de reproduire le constat sans multiplier inutilement les actions. Les horodatages, requêtes, réponses expurgées, captures et versions d'outils doivent être conservés de façon structurée.

La maîtrise de l'impact est constante. Si une action menace la disponibilité, expose des données non prévues ou sort du périmètre, le testeur s'arrête et suit la procédure définie. Une preuve minimale suffit souvent : démontrer l'accès à un enregistrement de test vaut mieux que télécharger une base entière.

Un pentest d'application Web ou d'API examine notamment l'authentification, l'autorisation, les sessions, les entrées, la logique métier et la configuration. Le guide WSTG de l'OWASP fournit une structure de tests, mais il doit être adapté à l'application.

Un pentest externe part d'une position proche d'un acteur sur Internet et étudie les services explicitement inclus. Un pentest interne simule une position convenue dans le réseau et peut examiner la segmentation, les permissions et les relations de confiance.

D'autres missions portent sur le mobile, le cloud, le Wi-Fi ou des équipements spécialisés. Elles demandent des connaissances et des précautions propres. Un exercice d'équipe rouge ajoute souvent des objectifs et des scénarios plus larges, parfois des dimensions humaines ou physiques. Il ne faut pas utiliser « red team » comme simple synonyme commercial de pentest.

Le référentiel PASSI de l'ANSSI distingue plusieurs activités d'audit, dont le test d'intrusion, l'audit de configuration, l'audit de code source, l'audit d'architecture et l'audit organisationnel et physique. Cette distinction rappelle qu'un pentester peut collaborer avec d'autres spécialistes et que le test d'intrusion n'est qu'une forme d'évaluation.

Le WSTG de l’OWASP fournit une structure pour les tests Web. En France, les référentiels PASSI de l’ANSSI décrivent des exigences applicables aux prestations qualifiées.

Le rapport est l'un des principaux livrables de la mission. Sa synthèse présente les objectifs, les principaux risques et les priorités dans un langage accessible aux décideurs. La partie méthodologique décrit le périmètre, les hypothèses, les dates, les accès, les exclusions et les limites. Sans ces éléments, le lecteur risque de surinterpréter les résultats.

Chaque constat technique doit comporter un titre précis et indiquer les actifs concernés, une description, des préconditions, une preuve minimisée, un impact, une sévérité justifiée et des recommandations. Les étapes de reproduction doivent être suffisamment claires pour l'équipe chargée de la correction. Le rapport doit par ailleurs rester accessible aux seuls destinataires autorisés.

Une recommandation utile distingue la correction immédiate d'une amélioration durable. « Mettre à jour » peut être nécessaire, mais il faut parfois aussi modifier un processus de déploiement, un contrôle d'accès ou une supervision. Le pentester doit éviter les formulations impossibles à appliquer et signaler les incertitudes.

La restitution orale permet de répondre aux questions et de corriger les malentendus. Les équipes techniques peuvent discuter de la faisabilité d'une remédiation. Les responsables peuvent arbitrer le risque. Une contre-vérification ultérieure, souvent appelée retest, porte sur les constats convenus. Elle ne constitue pas automatiquement un nouveau pentest complet.

Selon la mission, une journée peut être consacrée au cadrage, à la résolution d'un problème d'accès, aux vérifications techniques ou à la rédaction du rapport et à sa restitution. Certaines périodes sont très techniques. D'autres sont presque entièrement consacrées au rapport, à la relecture ou à la coordination.

La prise de notes en continu est essentielle. Reconstituer en fin de semaine une séquence complexe à partir de l'historique du terminal est risqué. Les preuves doivent être nommées, horodatées, expurgées et reliées au constat correspondant.

Les bases techniques couvrent les réseaux, les systèmes, le Web, l'identité, les permissions et les architectures. La programmation aide à lire une application, automatiser une tâche et adapter une preuve, mais le niveau nécessaire dépend des missions.

La méthode compte autant que les connaissances techniques : découper un problème, tenir un journal, vérifier une hypothèse et distinguer observation, interprétation et conclusion. Un constat bien rédigé permet aux équipes de comprendre le problème et de préparer sa correction. La communication orale adapte le niveau de détail au public sans masquer les limites.

L'éthique professionnelle se traduit par des comportements concrets : respecter le périmètre, minimiser les données, signaler un incident, protéger les preuves et ne pas réutiliser des accès. Le respect de ces règles est indispensable pour limiter les risques et conserver la confiance du commanditaire.

Le NICE Workforce Framework du NIST aide à distinguer les connaissances, compétences et tâches associées aux rôles cyber sans réduire le métier à une liste d’outils.

Tu évalues une application locale fictive appartenant à ton laboratoire. Deux comptes de test existent, alice-test et bob-test. Le scénario indique que tu as observé qu'en changeant l'identifiant numérique dans une URL, Alice peut afficher la facture fictive de Bob. Ne tente cette action sur aucun service réel.

Rédige une fiche comportant :

1. un titre factuel ;
2. le périmètre et les deux comptes de test ;
3. la précondition : être connecté avec le compte d'Alice ;
4. deux étapes de reproduction décrites sans données réelles ;
5. le résultat observé et le résultat attendu ;
6. l'impact possible ;
7. une preuve minimale à conserver ;
8. une recommandation côté serveur ;
9. une limite, puisque le cas est fictif et qu'aucun autre rôle n'a été testé.

Critère de réussite

La fiche est réussie si une autre personne comprend le défaut d'autorisation, sait quel contrôle doit être corrigé et voit clairement ce qui n'a pas été testé. La recommandation doit exiger une vérification d'autorisation côté serveur pour chaque objet, et non demander seulement de masquer l'identifiant dans l'interface.

Première erreur : réduire le métier à l'exploitation. Sans cadrage ni rapport, une démonstration technique ne répond pas au besoin du commanditaire. Deuxième erreur : accumuler des captures sans chaîne de raisonnement ni impact explicite.

Troisième erreur : dépasser le périmètre parce qu'une nouvelle cible semble liée. Il faut arrêter, documenter et demander une extension formelle. Quatrième erreur : conserver trop de données sensibles. Une preuve minimale et expurgée réduit le risque.

Le quotidien décrit ici reste général. Une mission courte dans une petite structure diffère d'un programme d'évaluation réglementé. Les outils, la part de déplacement, la pression temporelle et les responsabilités varient. Aucun article ne remplace l'expérience supervisée, les procédures de l'employeur ou un conseil juridique adapté.