La méthodologie d'un test d'intrusion : PTES et référentiels

Un test d'intrusion professionnel ressemble peu aux scènes de films où un pirate tape frénétiquement sur un clavier pendant quelques secondes. C'est un travail méthodique, planifié, documenté, qui se conclut par un rapport utile à ceux qui doivent corriger. Cette leçon présente les grandes étapes et les référentiels sur lesquels s'appuient les professionnels, pour que vous sachiez où chaque compétence acquise s'insère.

Dans la leçon précédente, vous avez vu qu'un test n'existe que dans un cadre autorisé. Reste à savoir comment le mener de façon reproductible : deux testeurs différents devraient suivre une démarche comparable et fournir des résultats comparables. C'est le rôle des méthodologies.

Qu'est-ce qu'un test d'intrusion ?

Un test d'intrusion (penetration test, souvent abrégé « pentest ») est une évaluation de sécurité autorisée au cours de laquelle un spécialiste simule les actions d'un attaquant, dans un périmètre et un temps donnés, pour identifier des faiblesses avant qu'un véritable attaquant ne les exploite. Le résultat n'est pas « j'ai réussi à entrer », mais une liste de constats priorisés, avec des recommandations de correction.

Il se distingue d'autres démarches :

• L'analyse de vulnérabilités : détection automatisée de failles connues, sans chercher à les exploiter. Plus large, moins profonde.
• L'audit de configuration ou de code : revue méthodique des paramètres ou du code source, par rapport à des bonnes pratiques.
• L'exercice de type « Red Team » : simulation plus longue et plus réaliste d'un adversaire, qui teste aussi la capacité de détection et de réaction de l'organisation.

Boîte noire, grise ou blanche

Le niveau d'information donné au testeur change la nature du test :

Le standard PTES en sept phases

Le PTES (Penetration Testing Execution Standard) est un cadre de référence qui décrit le déroulé d'une mission. Il comprend sept phases, que vous retrouverez sous des noms proches dans la plupart des méthodes.

1. Pre-engagement (préparation) : c'est la phase juridique et organisationnelle de la leçon précédente : objectifs, périmètre, règles d'engagement, autorisations, calendrier, contacts d'urgence. Rien de technique ne commence avant sa signature.
2. Intelligence gathering (collecte d'informations) : on rassemble tout ce qui est connu sur la cible : noms de domaine, adresses, technologies, employés. Une grande partie est de l'OSINT, c'est-à-dire du renseignement en sources ouvertes (leçon suivante).
3. Threat modeling (modélisation des menaces) : on identifie ce qui a de la valeur (données, services), qui voudrait l'attaquer et par quels chemins plausibles. Cela permet de concentrer l'effort sur ce qui compte.
4. Vulnerability analysis (analyse de vulnérabilités) : on cherche activement des faiblesses : ports ouverts, services obsolètes, mauvaises configurations, failles applicatives. On corrèle avec les bases publiques comme les identifiants CVE.
5. Exploitation : on vérifie que certaines failles sont réellement exploitables, dans les limites de ce qui est autorisé, pour démontrer l'impact et éliminer les faux positifs.
6. Post-exploitation : on mesure ce qu'un attaquant pourrait faire une fois entré (accès à d'autres machines, à des données sensibles), puis on remet l'environnement en état : suppression des comptes ou fichiers créés pendant le test.
7. Reporting (rapport) : la phase la plus importante pour le client. Un résumé pour les décideurs, des constats techniques avec preuves reproductibles, une gravité, des recommandations.

Le cycle n'est pas toujours linéaire : une information découverte en phase 4 peut vous renvoyer à la phase 2. Mais l'ordre général reste, et en particulier : on prépare et on cadre avant d'agir, et on rapporte à la fin.

Les référentiels à connaître

• NIST SP 800-115 : le guide technique du NIST (nist.gov) sur les tests et évaluations de sécurité. Il décrit la planification, l'exécution et la communication des résultats.
• OWASP Web Security Testing Guide (WSTG) : le guide de l'OWASP (owasp.org) pour tester les applications web, organisé par catégories (authentification, gestion de session, validation des entrées, etc.). Il sera votre ouvrage de référence dans le prochain cours.
• OWASP Top 10 : la liste des risques les plus répandus pour les applications web. Elle sert de langage commun.
• MITRE ATT&CK : une base de connaissances qui catalogue les tactiques et techniques observées chez de vrais attaquants (attack.mitre.org). Elle sert à décrire ce qu'un attaquant fait, à construire des scénarios réalistes et à vérifier la couverture de la détection.
• CVE et NVD : le système d'identifiants de vulnérabilités publiques (cve.org) et la base associée du NIST (nvd.nist.gov), avec description et score de gravité.

Pour évaluer la gravité d'une faille, on utilise souvent le score CVSS (de 0 à 10) : il combine la facilité d'exploitation et l'impact. Un bon rapport ne s'arrête pas au score : il tient compte du contexte. Une faille notée critique sur un serveur isolé sans donnée sensible peut être moins urgente qu'une faille moyenne sur un serveur exposé qui contient des données clients.

Le rapport : ce qui fait la valeur de la mission

Un rapport professionnel contient en général :

• Un résumé de direction en langage clair : ce qui a été testé, le niveau de risque global, les actions prioritaires.
• Le périmètre, la méthode et les dates, pour que le test soit reproductible.
• Pour chaque constat : une description, la gravité, les preuves (captures, extraits de journaux), les étapes de reproduction, et une recommandation concrète.
• Éventuellement les points positifs : ce qui est bien protégé.

Écrire clairement est donc une compétence centrale. Un testeur brillant dont le rapport est incompréhensible laisse le client sans solution.

Un exemple de constat bien rédigé (fictif)

Constat 03 - Service d'administration exposé sur le réseau interne
Gravité : Moyenne
Machine : cible (10.10.10.20), port 22/tcp

Description : Le service SSH accepte l'authentification par mot de passe
pour tous les comptes, y compris administrateur.
Preuve : sortie de la commande de configuration, ligne
"PasswordAuthentication yes" (capture jointe).
Impact : un attaquant du réseau interne pourrait tenter des
mots de passe courants sans limitation efficace.
Recommandation : désactiver l'authentification par mot de passe,
imposer des clés SSH protégées par phrase de passe, installer
une limitation des tentatives.

Remarquez la structure : un titre explicite, la gravité, la preuve, l'impact et surtout une recommandation actionnable. Le constat ne contient aucune méthode d'attaque détaillée : son but est d'aider à corriger.

À vous de jouer

1. Associez chaque activité à la phase PTES correspondante : (a) signer la lettre de mission ; (b) chercher les sous-domaines publics d'une entreprise fictive ; (c) rédiger les recommandations ; (d) dresser la liste des données sensibles et des chemins d'attaque probables ; (e) supprimer les comptes de test créés pendant la mission.
2. Dans votre laboratoire, rédigez un constat sur le laboratoire lui-même, sur le modèle ci-dessus : par exemple, la machine cible accepte l'accès SSH par mot de passe. Précisez gravité, preuve, impact, recommandation.
3. Parcourez la matrice sur attack.mitre.org et choisissez une tactique (par exemple l'accès initial) : écrivez en deux lignes ce qu'elle désigne.

La phase de collecte d'informations mérite qu'on s'y arrête : elle peut se faire sans jamais toucher le système visé. C'est l'objet de la leçon suivante.