Pentest boîte noire, grise ou blanche : quelles différences ?

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions de système d'information, d'application, de compte utilisateur, de vulnérabilité et de risque. Il est utile de comprendre ce qu'est un périmètre de test, mais aucun outil offensif n'est nécessaire.

Les termes boîte noire, boîte grise et boîte blanche décrivent le niveau d'information fourni au départ. Ils ne constituent ni une autorisation, ni une méthode complète, ni une garantie de couverture. Tout test actif doit reposer sur un accord écrit du commanditaire, limité aux systèmes qu'il possède ou pour lesquels il a obtenu l'accord des tiers concernés. L'exercice proposé reste entièrement sur papier.

Les expressions boîte noire, boîte grise et boîte blanche indiquent principalement ce que les auditeurs savent et quels accès ils possèdent avant de commencer. Elles ne désignent pas trois certifications et ne forment pas une échelle allant d'un test faible à un test supérieur. Elles répondent à des questions différentes.

En boîte noire, les auditeurs ne disposent normalement que des éléments nécessaires pour identifier les cibles autorisées, comme des adresses IP, des URL ou des noms de domaine. En boîte grise, ils reçoivent certaines informations sur le système et des privilèges associés à des profils légitimes. En boîte blanche, ils obtiennent un maximum d'informations pertinentes : architecture, configuration, documentation, code source ou comptes associés à plusieurs rôles.

Une boîte noire peut servir à observer une exposition depuis un point réseau convenu. Une boîte grise aide à étudier les droits d'un utilisateur ou les séparations entre rôles. Une boîte blanche permet de consacrer davantage de temps à des composants critiques grâce au contexte fourni. Le bon choix dépend donc de la question du commanditaire, de la durée et du niveau de preuve attendu.

Le mode ne définit pas à lui seul la méthode. Deux missions dites en boîte grise peuvent fournir des comptes, des documents et des contraintes très différents. La convention et la note de cadrage doivent énumérer concrètement les informations, privilèges, environnements et moyens mis à disposition. Les référentiels de qualification PASSI publiés par l'ANSSI replacent le test d'intrusion parmi plusieurs activités d'audit et fournissent le cadre institutionnel utile pour comprendre ces modalités.

Dans un pentest en boîte noire, le testeur reçoit peu d'informations internes. Le commanditaire lui transmet néanmoins les identifiants précis du périmètre autorisé : plages d'adresses, noms de domaine, URL, environnement concerné et exclusions. « Peu d'informations » ne signifie jamais « aucune limite ». Une découverte fortuite ne crée pas une autorisation.

Ce mode aide à examiner ce qui est visible depuis un point de départ déterminé. Il peut mettre en évidence des services exposés, des informations publiques utiles ou des comportements accessibles sans compte. Il faut cependant documenter le point d'observation. Un résultat obtenu depuis Internet ne décrit pas automatiquement ce qui serait possible depuis un réseau partenaire, un poste interne ou une autre région d'hébergement.

La découverte d'un domaine voisin, d'une adresse appartenant à un prestataire ou d'une ressource cloud ne permet pas de l'évaluer. Le testeur doit la signaler et attendre une extension formelle du périmètre si le commanditaire souhaite l'inclure. Cette règle protège les tiers et évite de transformer une erreur d'inventaire en action non autorisée.

La boîte noire consomme une partie du temps à reconstruire un contexte que le commanditaire connaît déjà. À durée égale, il peut rester moins de temps pour étudier la logique métier, les rôles authentifiés ou des composants peu visibles. Le rapport doit l'indiquer. L'absence de constat sur un composant non atteint ne démontre pas sa sécurité.

Ce mode est parfois présenté comme la reproduction parfaite d'un attaquant réel. Cette promesse est excessive. Un testeur respecte des horaires, des méthodes autorisées, un budget et des conditions d'arrêt. Il ne partage ni la patience, ni toutes les ressources, ni nécessairement les objectifs d'un acteur malveillant. Le pentest reste une évaluation bornée, réalisée à un instant donné.

En boîte grise, le testeur reçoit un ensemble limité mais utile d'informations internes. Il peut disposer d'un schéma d'architecture simplifié, d'une description des fonctions importantes, de comptes de test ou d'informations sur les rôles. L'objectif consiste souvent à réduire le temps consacré à la découverte pour approfondir les contrôles qui intéressent le commanditaire.

Pour une application, plusieurs comptes fictifs peuvent représenter un client, un gestionnaire et un administrateur. Pour une infrastructure interne, le point de départ peut être un poste de test rattaché à un segment déterminé avec un compte utilisateur ordinaire. Ces positions doivent être décrites sans ambiguïté. Un compte annoncé comme standard, mais doté de droits inconnus, fournit un point de départ mal maîtrisé.

La boîte grise convient notamment à l'étude des séparations entre rôles, des parcours authentifiés, des droits associés à un utilisateur légitime et des relations entre plusieurs zones. Elle ne suppose pas qu'un salarié réel est hostile. Elle utilise un profil convenu pour vérifier si les contrôles correspondent aux règles attendues.

La qualité des comptes fournis influence directement la couverture. Un compte bloqué, incomplet, rattaché au mauvais rôle ou dépourvu de données représentatives réduit la valeur des conclusions. Le testeur doit vérifier les accès au début de la mission et signaler les écarts. Le temps perdu, les fonctions indisponibles et les remplacements de compte sont consignés dans les limites.

Les données de test doivent être identifiables et distinctes des données réelles lorsque c'est possible. Si le testeur rencontre des informations personnelles, des secrets ou un environnement tiers non prévus, il applique la procédure d'arrêt ou de signalement définie au cadrage. La présence d'un compte ne donne pas carte blanche : chaque action reste soumise aux mêmes restrictions opérationnelles et au même besoin de proportionnalité.

En boîte blanche, le testeur reçoit le maximum d'informations utiles à la mission. Selon le système, cela peut comprendre les schémas d'architecture, les flux, la documentation des API, la configuration, le code source, l'inventaire des composants, les comptes de plusieurs rôles et les choix de sécurité attendus.

Ce contexte permet de cibler les vérifications. Le testeur peut rapprocher un comportement observé d'un contrôle prévu, identifier plus rapidement les composants sensibles et examiner des hypothèses qui resteraient difficiles à atteindre depuis l'extérieur. La boîte blanche est particulièrement adaptée lorsqu'une organisation veut utiliser un temps limité pour étudier en profondeur une application critique ou une zone déjà identifiée comme importante.

Disposer du code source ne transforme toutefois pas automatiquement la mission en audit complet du code. La revue de code peut constituer une activité distincte avec sa propre méthode, son propre échantillonnage et ses propres livrables. Si le contrat prévoit seulement un pentest, le code peut guider les tests sans que chaque fichier soit relu. Cette limite doit être explicite.

La documentation peut également être incomplète ou obsolète. La version transmise peut différer de celle qui est déployée et un composant tiers peut rester hors périmètre. Le rapport précise donc les documents, branches, versions, configurations et environnements réellement utilisés. Il distingue ce qui a été vérifié de ce qui a seulement été déclaré.

Le NIST SP 800-115 organise l'évaluation autour de la planification, de l'exécution et des activités postérieures au test. Ce guide souligne aussi l'importance des contraintes, de la logistique, des données collectées et de la réduction du risque. Une boîte blanche ne supprime aucune de ces étapes. Elle change le contexte disponible, pas les obligations de prudence.

Le choix doit partir de l'objectif, et non d'une préférence commerciale.

Besoin principal	Mode souvent pertinent	Informations de départ possibles	Limite à documenter
Examiner l'exposition externe depuis un point convenu	Boîte noire	Domaines, URL, adresses et exclusions	Temps consacré à la découverte, faible visibilité interne
Étudier les droits d'un utilisateur ou les séparations entre rôles	Boîte grise	Comptes de test, rôles, parcours et architecture simplifiée	Résultats dépendants des profils fournis
Approfondir un composant critique	Boîte blanche	Architecture, configuration, code, documentation et comptes	Documentation potentiellement incomplète, échantillonnage nécessaire
Répondre à plusieurs questions	Approche hybride	Niveau d'information différent selon chaque phase	Transitions et hypothèses à tracer

Une mission peut combiner les modes. Le testeur peut commencer avec peu d'informations pour observer l'exposition, puis recevoir des comptes et de la documentation pour approfondir certaines fonctions. Il faut distinguer les phases dans les notes et dans le rapport. Le lecteur doit savoir si un constat était accessible sans compte ou s'il dépendait d'un accès fourni.

Quel que soit le mode, l'autorisation écrite et les règles d'engagement restent indispensables. Celles-ci précisent les cibles incluses et exclues, les dates, les adresses sources des testeurs, les comptes, les actions interdites, les seuils d'impact, les conditions d'arrêt, les contacts d'urgence et le traitement des preuves. Elles couvrent également le cas d'un incident réel ou de la découverte d'un système tiers.

La boîte blanche n'autorise pas davantage d'actions que la boîte noire. Elle fournit seulement plus d'informations. Inversement, une boîte noire ne dispense jamais le commanditaire de révéler les limites nécessaires à la sécurité de la mission. Une preuve proportionnée doit être préférée à une action destructive ou à une collecte massive de données.

Le Web Security Testing Guide de l'OWASP rappelle que la stratégie de test dépend du contexte, du modèle de menace et de l'information disponible. Demander simultanément une boîte noire très large, une analyse détaillée de la logique métier et une revue complète du code dans une durée courte crée des objectifs incompatibles. Il faut réduire le périmètre, augmenter le temps ou répartir les activités.

Cet exercice est strictement limité à un scénario fictif écrit. Tu ne dois utiliser aucun outil, envoyer aucune requête ni choisir une cible réelle.

Une entreprise fictive prépare le portail RH rh.exemple.test. Le domaine réservé .test sert uniquement dans l'énoncé. Le portail comporte trois rôles fictifs : salarié, responsable d'équipe et gestionnaire RH. Le commanditaire formule trois besoins indépendants :

1. observer ce qu'un visiteur non authentifié peut apprendre depuis la page publique ;
2. vérifier si un salarié peut consulter les dossiers fictifs d'un autre salarié ;
3. examiner en profondeur la conception des contrôles d'accès avant la mise en production.

Pour chaque besoin, écris une fiche contenant le mode retenu, les informations et comptes fournis, la question précise, une limite de couverture, deux exclusions, une condition d'arrêt et le type de preuve minimale attendu. Ajoute ensuite une quatrième fiche décrivant une approche hybride : une première phase avec seulement l'URL fictive, puis une seconde avec les trois comptes de test et la documentation des rôles. Explique comment le rapport distinguera les observations des deux phases.

Critère de réussite

L'exercice est réussi si le premier besoin est associé à une boîte noire, le deuxième à une boîte grise et le troisième à une boîte blanche, avec une justification liée au niveau d'information et non à une prétendue supériorité. Chaque fiche doit définir un périmètre, une limite, des exclusions et une condition d'arrêt. La fiche hybride doit permettre de savoir si chaque constat vient de la phase non authentifiée ou d'un accès fourni. Aucune action technique ne doit être proposée.

Erreurs à éviter

Ne choisis pas la boîte noire uniquement parce qu'elle paraît plus réaliste. Ne suppose pas que la boîte blanche est exhaustive. Ne transforme pas un compte de test en permission générale. Enfin, ne confonds pas le mode de connaissance avec la nature de l'audit : un test d'intrusion, une revue d'architecture, un audit de configuration et une revue de code peuvent se compléter sans devenir la même activité.