Notre méthodologie de test d'intrusion.
Un test d'intrusion se juge autant sur son cadre que sur ses résultats. Ce qui suit décrit ce qui est fixé avant de commencer : sur quels référentiels nous nous appuyons, dans quel ordre nous travaillons, ce que nous nous interdisons, et à quel moment vous êtes prévenu. Rien de tout cela n'est négociable en cours de route.
L'outil pour couvrir, la main pour trouver.
Un test d'intrusion sérieux combine deux régimes de travail qu'on confond souvent. Le premier est mécanique : inventorier les points d'entrée, vérifier les versions, dérouler une liste de contrôles connus. Un outil le fait mieux et plus vite qu'un humain, et s'en priver n'aurait aucun sens.
Le second ne s'automatise pas. Il consiste à comprendre ce que votre application est censée faire, puis à chercher où cette intention n'a pas été traduite correctement dans le code. Aucun outil ne sait qu'un utilisateur ne devrait pas pouvoir valider sa propre demande de remboursement, parce que cette règle n'existe nulle part ailleurs que dans votre métier.
Toute notre méthode découle de ce partage. Nous outillons au maximum la première partie pour libérer du temps sur la seconde, qui est la seule à trouver les failles qui coûtent vraiment cher. Et aucun résultat d'outil n'entre dans un rapport sans avoir été rejoué à la main : sur un scan brut, la majorité des alertes remontées n'existent pas.
Sur quoi nous nous appuyons.
Les référentiels ne remplacent pas la recherche : ils garantissent qu'aucune famille de failles n'est passée sous silence pendant qu'on creuse ailleurs.
OWASP WSTG
Le guide de test des applications web. Il sert de liste de couverture : authentification, gestion de session, autorisation, validation des entrées, logique métier, configuration. Chaque catégorie est passée en revue et tracée.
OWASP API Security Top 10
Le classement propre aux API, qui ne recouvre pas celui du web. L'autorisation par objet et par fonction y occupe les premières places, et c'est effectivement là que se concentre l'essentiel de ce que nous trouvons.
Structure PTES
Pour la conduite de mission plutôt que pour le contenu technique : cadrage, collecte, modélisation des menaces, exploitation, post-exploitation, restitution. C'est la colonne vertébrale du déroulé.
Le déroulé d'une mission.
Cadrage et autorisation
Périmètre écrit, adresses concernées, fenêtre de test, contact joignable, comptes fournis. L'autorisation écrite est signée : sans elle, il n'y a pas de mission, quel que soit le prestataire. Le NDA précède tout échange technique.
Reconnaissance
Ce qui est réellement joignable à votre nom : sous-domaines, environnements annexes, technologies en place, points d'entrée oubliés. Cette phase est la seule où un périmètre plus large que prévu peut apparaître, et c'est le moment de le dire.
Cartographie fonctionnelle
Nous parcourons l'application comme un utilisateur légitime, avec chaque rôle, et nous notons ce que chacun peut faire. Cette carte est ce qui permettra ensuite de distinguer une requête normale d'un franchissement de frontière.
Recherche et exploitation
Le cœur de la mission. Chaque hypothèse est vérifiée sur l'application réelle, pas déduite d'une version affichée. Une faille n'entre dans le rapport que si nous l'avons exploitée et que nous en avons la preuve reproductible.
Post-exploitation contrôlée
Une fois une brèche ouverte, nous mesurons jusqu'où elle mène : quelles données deviennent accessibles, quelles autres fonctions s'ouvrent, quel enchaînement devient possible. Nous nous arrêtons à la démonstration, sans jamais extraire ni altérer de données réelles.
Rapport, restitution, retest
Rédaction, remise, puis une heure d'échange avec ceux qui vont corriger. Après déploiement des correctifs, nous rejouons les tests concernés et nous confirmons par écrit ce qui est fermé. Voici à quoi ressemble le rapport.
Ce que nous nous interdisons.
Ces règles sont écrites dans chaque autorisation de test. Elles existent pour que la mission ne devienne jamais elle-même l'incident.
- Aucun déni de service, aucun test de charge, aucune tentative de saturation, sauf demande écrite et explicite de votre part.
- Aucune action destructrice sur des données réelles : pas de suppression, pas de modification de contenu appartenant à vos utilisateurs.
- Aucune extraction de données personnelles au-delà de la preuve minimale nécessaire pour démontrer la faille.
- Aucun test en dehors du périmètre écrit, même si une porte voisine paraît ouverte. Elle est signalée, elle n'est pas franchie.
- Aucune ingénierie sociale visant vos collaborateurs, sauf mission spécifique convenue à l'avance.
- Toute vulnérabilité critique est signalée le jour même, sans attendre la remise du rapport.
- Journal horodaté des tests conservé, pour que vous puissiez distinguer notre activité d'une attaque réelle dans vos propres traces.
- Destruction des données de mission et des preuves après la période de conservation convenue.
Boîte noire, grise ou blanche.
Le niveau d'information que vous nous donnez change ce que la mission peut atteindre. Dans la pratique, une seule option est presque toujours la bonne.
Boîte grise, le choix par défaut
Vous fournissez des comptes, pas le code. Nous partons du même point qu'un attaquant qui a réussi à s'inscrire, ce qui est le scénario réel dans l'immense majorité des cas. Meilleure couverture pour un budget donné.
Boîte noire
Aucune information, aucun compte. Réaliste pour évaluer l'exposition d'une surface publique, mais coûteuse : une partie des jours part en reconnaissance plutôt qu'en recherche, et tout ce qui est derrière l'authentification reste hors de portée.
Boîte blanche
Accès au code source en lecture. Pertinent sur un composant sensible et spécifique : moteur de droits, calcul financier, cryptographie maison. Peu rentable sur une application complète.
Ce qui ne change jamais
Quelle que soit l'approche, les règles d'engagement, l'alerte immédiate sur critique et le retest inclus restent identiques.
Questions fréquentes.
Suivez-vous une norme reconnue ?
Nous nous appuyons sur l'OWASP Web Security Testing Guide et sur l'OWASP API Security Top 10, complétés par la structure du PTES pour la conduite de mission. Ce sont des référentiels de couverture : ils garantissent qu'aucune famille de failles n'est oubliée. Ils ne remplacent pas la recherche propre à votre application, qui est l'essentiel du travail.
Boîte noire, grise ou blanche : laquelle choisir ?
La boîte grise dans la quasi-totalité des cas : vous fournissez des comptes, pas le code. C'est le meilleur rapport entre le réalisme et la couverture. La boîte noire complète fait perdre des jours en reconnaissance pour un gain de réalisme faible, et la boîte blanche n'a d'intérêt que sur du code sensible et spécifique.
Testez-vous en production ?
Oui, c'est même le cas le plus fréquent, et c'est sans danger dès lors que les règles sont posées : pas de déni de service, pas d'action destructrice, données de test créées pour l'occasion, requêtes espacées. Un environnement de recette fidèle reste préférable quand il existe, parce qu'il autorise des manipulations qu'on s'interdit ailleurs.
Que se passe-t-il si vous trouvez quelque chose de critique ?
Nous vous prévenons le jour même, sans attendre le rapport, avec de quoi comprendre et contenir immédiatement. C'est une règle fixée avant la mission, et c'est la raison pour laquelle nous demandons toujours un contact joignable pendant la fenêtre de test.
Utilisez-vous des outils automatiques ?
Oui, pour ce qu'ils font bien : inventorier, répéter, mesurer, ne rien oublier de mécanique. Aucun résultat d'outil n'entre dans le rapport sans avoir été rejoué et confirmé à la main. L'outillage couvre ce qui est déjà catalogué, ce qui libère du temps pour ce qui vous est propre.
Pour aller plus loin.
Combien coûte un pentest
Cette méthode se traduit en jours de recherche. Les six variables qui déterminent le montant, et ce qui est compris dans chaque mission.
DécouvrirPentest ou scan de vulnérabilités
Où s'arrête l'outil, où commence la recherche manuelle, et pourquoi les deux ne répondent pas à la même question.
DécouvrirParlons de votre périmètre.
Décrivez ce que vous voulez faire tester et nous vous proposons un cadrage : approche, phases, durée et règles d'engagement, avant tout engagement de votre part. Premier échange sans engagement, confidentialité totale.