Les types de test : boîte noire, boîte grise, boîte blanche

« Faites-moi un pentest. » Cette demande, en apparence simple, cache une question essentielle : qu'est-ce que le testeur sait de la cible avant de commencer ? La réponse change la durée, le coût, la profondeur et même la nature des résultats. Cette leçon vous donne le vocabulaire pour poser les bonnes questions.

Dans la leçon précédente, vous avez retenu que l'autorisation et le périmètre définissent un test légal. Il reste à choisir comment mener ce test. Trois grandes familles existent, qui se distinguent par le niveau d'information donné au testeur : la boîte noire, la boîte grise et la boîte blanche.

La boîte noire : se mettre dans la peau d'un inconnu

En boîte noire, le testeur reçoit très peu d'informations : parfois seulement le nom de l'organisation, une plage d'adresses ou une adresse de site. Il doit tout découvrir seul, comme le ferait un attaquant externe qui n'a aucun accès privilégié.

• Avantages : simulation réaliste d'une attaque externe ; permet de mesurer ce qui est visible depuis l'extérieur ; peut tester la capacité de l'organisation à détecter un comportement suspect.
• Limites : beaucoup de temps passé en reconnaissance ; des zones profondes de l'application ou du réseau peuvent rester inexplorées ; à budget égal, moins de failles trouvées.

Analogie : un inspecteur qui évalue la sécurité d'un bâtiment sans plan ni clef, en observant seulement la rue, les portes et les fenêtres.

La boîte blanche : l'audit avec tous les plans

En boîte blanche (ou « cristal »), le testeur reçoit l'information complète : schémas d'architecture, documentation, comptes avec différents niveaux de privilèges et parfois le code source. Le but n'est plus de simuler un inconnu, mais de trouver le maximum de faiblesses avec le temps disponible.

• Avantages : couverture très élevée ; les failles profondes (logique métier, configuration interne, erreurs de conception) sont plus facilement trouvées ; efficacité du temps de test.
• Limites : ne reflète pas ce que verrait un attaquant externe ; demande un client prêt à partager des informations sensibles ; peut mobiliser des équipes internes pour répondre aux questions.

Analogie : l'inspecteur reçoit les plans du bâtiment, le trousseau complet et la liste des systèmes d'alarme, puis vérifie chaque pièce.

La boîte grise : le compromis le plus courant

La boîte grise se situe entre les deux : le testeur reçoit des informations partielles, typiquement un compte utilisateur standard, une documentation d'API, un schéma réseau simplifié. Il simule par exemple un utilisateur légitime malveillant, un partenaire ou un attaquant qui a déjà obtenu un premier accès.

C'est souvent la formule recommandée : elle évite de gaspiller du temps à redécouvrir ce que le client sait déjà, tout en restant plus proche d'une situation réaliste qu'un audit entièrement documenté.

Tableau comparatif

D'autres axes qui se combinent avec les trois couleurs

La couleur de la boîte n'est qu'un axe parmi d'autres. En pratique, un pentest se décrit aussi par :

• La position : test externe (depuis Internet), interne (depuis le réseau de l'entreprise, par exemple avec un poste branché ou le compte d'un employé), ou depuis un poste de télétravail ;
• La cible : application web, application mobile, infrastructure réseau, Wi-Fi, système industriel, humains (ingénierie sociale, uniquement si le contrat le prévoit explicitement) ;
• La discrétion : test annoncé (l'équipe de défense est prévenue) ou non annoncé (pour évaluer la détection) ;
• L'objectif : trouver un maximum de failles (pentest classique) ou atteindre un objectif précis en restant discret (exercice de type « red team », que vous croiserez dans le dernier cours).

Les référentiels de la profession (le guide technique du NIST, la méthodologie d'OWASP pour le web, ou des standards comme PTES et OSSTMM) décrivent tous ces choix. Vous n'avez pas à les connaître par cœur : retenez qu'ils existent et qu'un rapport sérieux explique quelle approche a été retenue.

Comment choisir ? Quelques questions à poser au client

1. Quel est votre objectif : vérifier une application avant sa mise en production, répondre à une exigence réglementaire, tester la réaction de vos équipes ?
2. Quelles sont les cibles les plus critiques pour votre activité ?
3. Quel budget et quel délai ? Plus l'information est donnée, plus le temps du testeur est consacré à la recherche de failles plutôt qu'à la découverte.
4. Souhaitez-vous que vos équipes de supervision soient prévenues ?
5. Quelles informations pouvez-vous partager sans risque (comptes de test, documentation) ?

Trois idées reçues à écarter

• « La boîte noire est plus sérieuse parce qu'elle est plus dure. » Faux : elle est plus réaliste sur un angle précis, mais elle trouve en général moins de failles dans le même temps. Un attaquant réel dispose de semaines ou de mois, un prestataire de quelques jours.
• « La boîte blanche, c'est tricher. » Faux : un attaquant motivé finit souvent par obtenir des informations internes (fuite de documentation, compte compromis, ancien employé). Tester avec ces informations permet d'anticiper ce scénario.
• « Un seul test suffit. » Faux : un système évolue, de nouvelles failles sont publiées chaque semaine. Un test est une photographie à une date donnée, pas un certificat de sécurité durable.

Cette dernière remarque se retrouvera dans le rapport : un bon testeur précise toujours que son travail est borné dans le temps et dans le périmètre, et qu'une absence de découverte ne prouve pas l'absence de faille.

Notre fil rouge : un choix en boîte grise

Pour la mission d'entraînement de ce cours, nous allons nous placer en boîte grise. Le « client » fictif, que nous appellerons la société Verdelune, est une petite entreprise imaginaire dont le système d'information est représenté par un petit réseau de machines volontairement vulnérables dans votre labo. Vous recevrez (ou plutôt, vous vous donnerez à vous-même) un schéma simplifié du réseau et la liste des services attendus, sans les détails de configuration. La personne de Verdelune n'existe pas : elle sera jouée par vous-même, ce qui est parfait pour s'entraîner à formaliser les choses.

À vous de jouer : qualifier trois demandes

Pour chacune des trois demandes fictives suivantes, indiquez le type de test (noir, gris, blanc) que vous recommanderiez et pourquoi :

1. Une start-up veut valider son application web avant un lancement dans trois semaines. Elle peut fournir des comptes de test et sa documentation d'API.
2. Une collectivité fictive veut savoir ce qu'un inconnu pourrait trouver sur ses services accessibles depuis Internet.
3. Une équipe de développement fictive veut une revue la plus complète possible d'un module sensible, avec accès au code.

Dans la prochaine leçon, nous transformerons ces choix en documents concrets : l'autorisation écrite et le périmètre.