Notre méthodologie de test d'intrusion, du cadrage au retest.
Un test d'intrusion se juge autant sur son cadre que sur ses résultats. Voici ce qui est fixé avant de commencer : les référentiels, l'ordre de travail, ce que nous nous interdisons, et à quel moment vous êtes prévenu. Rien de tout cela ne se négocie en cours de route.
En bref
- RéférentielsOWASP WSTG, OWASP API Security Top 10, et la structure du PTES pour la conduite de mission.
- ApprocheBoîte grise dans la plupart des cas, avec des comptes de test fournis par vous.
- Ce que nous nous interdisonsNi déni de service, ni test de charge, ni action destructrice sur des données réelles.
- Ce qui déclenche une alerteToute faille critique, signalée le jour même, sans attendre le rapport.
Nos outils pour couvrir, notre expertise pour trouver.
Nos outils couvrent tout ce qui se vérifie mécaniquement. Le reste demande de comprendre comment votre application doit fonctionner.
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. Nos outils maison le font 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.
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, celle qui trouve les failles qu'un outil ne voit pas. Et aucun résultat d'outil n'entre dans un rapport sans avoir été rejoué et confirmé : sur un scan brut, une bonne partie des alertes sont de fausses alertes.
Deux régimes de travail. L'outil libère du temps, et ce temps va à ce qui est propre à votre application.
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
Couverture web
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
Couverture API
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 là que nous trouvons une grande partie des failles d'API.
Structure PTES
Conduite de mission
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.
Six phases, toujours dans cet ordre. Chacune a sa sortie, et la suivante ne commence pas sans elle.
Voir le rapport qui en sort- 01
Cadrage et autorisation
Périmètre écrit, URLs concernées, fenêtre de test, contact joignable, comptes fournis. Le NDA est signé dès que l'on entre dans le détail technique. Une fois le devis signé, la convention d'autorisation de test d'intrusion l'est à son tour : sans elle, il n'y a pas de mission, quel que soit le prestataire.
- 02
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.
- 03
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.
- 04
Recherche et exploitation
Le cœur de la mission. Chaque hypothèse est vérifiée sur l'application réelle, jamais 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.
- 05
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.
- 06
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é.
Ce que nous nous interdisons.
Ces règles sont écrites dans chaque convention d'autorisation de test d'intrusion. 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.
Rien de destructif
Pas de suppression, pas de modification de contenu appartenant à vos utilisateurs.
Rien au-delà de la preuve
Aucune donnée personnelle extraite au-delà de la preuve minimale nécessaire pour démontrer la faille.
Rien hors 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
Rien qui vise vos collaborateurs, sauf mission spécifique convenue à l'avance.
Une alerte le jour même
Toute vulnérabilité critique est signalée le jour même, sans attendre la remise du rapport.
Un journal horodaté
Conservé pour que vous puissiez distinguer notre activité d'une attaque réelle dans vos propres traces.
Des données détruites
Les données de mission et les preuves sont détruites 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 noire : rien au départ
- Vous fournissez
- Aucune information, aucun compte.
- Le test atteint
- L'exposition d'une surface publique. 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.
- À choisir quand
- Pour évaluer ce qu'un inconnu voit depuis Internet.
Boîte grise, le choix par défaut Notre conseil
- Vous fournissez
- Des comptes de test, sans accès au code.
- Le test atteint
- Le même point de départ qu'un attaquant qui a réussi à s'inscrire ou à obtenir un compte, un scénario très courant.
- À choisir quand
- Presque toujours : la meilleure couverture pour un budget donné.
Boîte blanche : le code en lecture
- Vous fournissez
- Un accès au code source en lecture.
- Le test atteint
- Aussi la logique écrite dans un composant sensible : moteur de droits, calcul financier, cryptographie maison.
- À choisir quand
- Sur un composant sensible et spécifique. Peu rentable sur une application complète.
Quelle que soit l'approche, les règles d'engagement, l'alerte immédiate sur une faille critique et le retest inclus restent identiques.
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 de test, sans accès au 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. Une préproduction fidèle reste préférable quand elle existe, parce qu'elle autorise des manipulations qu'on s'interdit ailleurs.
Que se passe-t-il si vous trouvez quelque chose de critique ?
Vous l'apprenez le jour même, pas à la remise du rapport : la faille, sa preuve et de quoi la contenir tout de suite. Cette règle est écrite dans la convention d'autorisation de test, et c'est pour elle que nous demandons un contact joignable pendant toute la fenêtre de test.
Utilisez-vous des outils automatiques ?
Oui, nos outils maison, 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é. 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.
La méthode se traduit en jours, en livrable et en prestations.
Combien coûte un pentest
Cette méthode se traduit en jours de recherche : nos tarifs et ce qui fait varier le montant.
Voir la pageExemple de rapport
Ce que produit la sixième phase : les huit sections du rapport, et une faille de bout en bout.
Voir la pagePentest ou scan de vulnérabilités
Où s'arrête l'outil, où commence la recherche, et pourquoi les deux ne répondent pas à la même question.
Voir la pageToutes les prestations
Les cinq prestations qui appliquent cette méthode.
Voir la pageParlons de votre périmètre.
Décrivez ce que vous voulez faire tester. Nous vous proposons un cadrage avec l'approche, les phases, la durée et les règles du test. Le premier échange est sans engagement.