Pentest sur la production ou non ?

Un nouvel appel d'offre tombe, on nous propose d'auditer un système de gestion de chèques. Il est demander de faire des tests de corruption de données. "Avez-vous des questions ? - Oui, s'agira-t-il d'un système en production ? - Tout à fait cela sera en production."

Très bien monsieur le client ! Vos désirs seront nos ordres. Il n'est évidemment pas de notre ressort de contredire le client surtout dans un appel d'offre... Mais juste juste pour rappel, ce n'est pas parce qu'on est assuré professionnellement pour ce type d'activité qu'on sera tenu responsable en cas d'incident. En effet le client est responsable de ce qu'il demande de faire sur son SI. Le pentester doit rappeler les risques et le client valide (accepte de prendre la responsabilité). Lorsqu'on veut faire un débordement de tampon, on pose la question avant le test en précisant que le service peut devenir instable et qu'il faudra peut-être le relancer par la suite. Le pentester se dégage alors de toute responsabilité si le client accepte de faire le test.

Cela étant dit, pourquoi les clients nous demandent de faire des tests en production ? Est-ce mieux ou moins bien que sur un système en pré-production ?

Je vois plusieurs raisons à ce problème :

• On n'a pas de pré-production :)
  Une recette alors ? Euh chez le prestataire chargé du développement, mais on n'y a pas accès.
  Il y a effectivement encore beaucoup de systèmes gérés à l'arrache sans environnements de pré-production et recette. Comment font les équipes pour être sûres qu'une mise à jour fonctionnera correctement ? Ca pourrait être une vulnérabilité à mettre dans notre rapport...
  Alors faites bien une sauvegarde avant l'audit et chaque soir. Oui, il faut le rappeler... Et donnez-nous un contact à appeler si le système devient indisponible.
  Bref on bosse sur un système vivant, mais avec beaucoup de contraintes et de risques.
• On a un système qui vient d'être livré (en production) et pas encore d'utilisateurs, donc aucun impact sur la production. Sauf qu'il est vierge... Les bases de données sont vides.
  Dans certains cas cela n'est pas gênant, mais de plus en plus de fonctions ne sont accessibles que lorsque des données sont présentes en base. Il faut demander à ce que de fausses données soient présentes ou bien une copie de la production.
  Il m'est arrivé plusieurs fois récemment de faire un pentest à la fin du développement d'un projet, avant qu'il soit mis en production. Il n'y a rien de pire que de tester un système vierge, par exemple un site de recrutement dans lequel il n'y a pas d'offre d'emplois et aucun profil de candidat... Il faut alors se palucher les modes d'emploi et découvrir le fonctionnement du site.
  Encore pire, le système était en cours de livraison. Les fonctions arrivaient les unes après les autres. Le lundi on voyait une page d'erreur avec un mot de passe en clair, puis le mardi une nouvelle partie du site apparaît à la place...
• On a bien un système en pré-production, mais il n'est pas interfacé avec le même annuaire et avec les mêmes webservices.
  A la rigueur on peut travailler en pré-production, puis faire les tests de contournement d'authentification en production.
• On a un système en production avec des données similaires à la production et toutes anonymisées.
  Voilà, on y est. C'est le Paradis. Sauf que j'en ai entendu parler et je ne l'ai jamais vu :)

Bref, le pentester a beaucoup de donne volonté, mais si on ne lui donne pas les bonnes conditions pour réaliser tous les tests correctement, il va éviter de faire ceux qui peuvent secouer la production comme une blind SQL injection ou alors il va rater des fonctions car elles n'étaient pas activées faute de données disponibles. Et on ne pourra pas le tenir responsable.

Alors cher client, si tu veux rentabiliser ton audit en optimisant le temps de travail des auditeurs pour qu'ils trouvent le plus possible de vulnérabilités, prépare leur un beau terrain de jeu en pré-production avec des données représentatives.