Comment se déroule un test d'intrusion — comment gérer le process sans coupure sur un site en production ?

La règle d'or pour éviter le crash, c'est de limiter la fréquence des requêtes (rate limit) des scanners. Imposez à l'équipe de test un plafond de 5 à 10 requêtes max par seconde. Et exigez surtout que les injections massives ciblant les moteurs de recherche de la base (qui lancent de lourds filtrages) soient faites à la main et de façon hyper contrôlée.

Les clauses indispensables dans le cahier des charges : 1) Pas d'attaques DoS/DDoS ni de brute-force sur la prod, 2) Aucune suppression ou modification de données en base de prod, 3) Tests uniquement réalisés entre 01h00 et 06h00, 4) Notification immédiate en cas de découverte d'une faille critique, sans attendre la remise du rapport.

Lors de notre premier pentest, le testeur a lancé un outil auto sur le formulaire d'inscription, ce qui a déclenché notre service de validation SMS. En trois heures, 14.000 SMS sont partis et l'opérateur a bloqué notre ligne pour suspicion de spam. Pensez absolument à basculer les services externes (SMS, notifications, passerelles de paiement) en mode sandbox/mock avant de lancer le test.

Votre client exige un audit certifié par un organisme d'État (type TSE) ou un rapport d'un cabinet certifié à l'international (CREST, OSCP, etc.) lui suffit ? Selon la réponse, les prestataires à consulter et le budget n'auront rien à voir.

On a fait faire un test en boîte grise pour notre plateforme B2B de taille similaire. Ça a duré 5 jours ouvrés au total. Ils ont trouvé 2 failles critiques et 4 moyennes. En calant bien les créneaux horaires, l'utilisation CPU des serveurs n'a jamais dépassé les 40 % et on n'a eu aucune coupure.

Si votre infra le permet, faites un clone exact de votre environnement sur un serveur de staging avec une copie anonymisée/masquée de la base de prod. En faisant tester cet environnement miroir vous ne prenez aucun risque sur les commandes et les utilisateurs en direct.

Pas d'angoisse inutile : aucun expert sérieux ne va s'amuser à faire tomber un système en prod. Tant que vous gardez une bonne communication et que vous excluez les tests de DoS, tout se passera sans accroc.

PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.

Avant de démarrer, faites obligatoirement signer un accord de confidentialité (NDA) et une lettre d'autorisation en bonne et due forme. C'est essentiel pour délimiter les responsabilités légales et vous assurer de garder le pouvoir d'interrompre le test à tout moment sur le plan de la gouvernance de sécurité.

Il y a un point auquel il faut faire attention. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

Il faut y aller étape par étape. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

J'espère que cela vous sera utile.

Je suis intéressé.

Je ne savais pas ça.

Chez moi c'est l'inverse qui s'est passé c'est pourquoi j'écris. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

C'est confirmé par l'expérience.

Nous avons aussi bloqué au même endroit à une époque. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Je le note au cas où.

Ce conseil ne convient pas à tout le monde, je pense. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Merci d'avoir écrit cela, c'est exactement ça. Si vous grondez les fausses alertes, plus personne ne signalera rien.

Bien sûr, cela change si votre situation est différente.

Je pense différemment. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

À votre place j'irais par cette voie.

Pourriez-vous préciser un peu ? La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Je suis aussi curieux de savoir si d'autres font autrement.