Acheter des outils de pentest et tester nous-mêmes ou est-ce une mauvaise idée ?

Séparez bien les choses : 1) Le scan de vulnérabilités est automatique, il cherche les failles connues via des outils. 2) Le pentest, c'est tester avec une réflexion humaine si l'on peut concrètement s'infiltrer et accéder aux données derrière une faille. Votre client veut le second, avec votre outil vous ne ferez que le premier.

Attention si vous scannez vous-mêmes avec un outil auto : les outils bombardent les formulaires web avec des données non contrôlées. En prod, ça va injecter des centaines de faux enregistrements dans votre BDD, et si vous avez des intégrations de paiement ou de SMS, ça peut déclencher des milliers d'appels d'affilée et griller vos crédits d'API en quelques minutes. Ne testez jamais ça directement en prod.

On a fait la même bêtise il y a deux ans. On a envoyé le rapport de scan de notre propre outil à un client bancaire. Leurs équipes de sécurité nous ont tout de suite fait remarquer que les 14 alertes critiques étaient des faux positifs, alors qu'une simple faille de contrôle d'accès n'apparaissait même pas dans le rapport. La perte de crédibilité nous a coûté bien plus cher que les 4.000 GBP économisés.

Êtes-vous sûrs que la boîte qui propose 5.500 GBP va réellement faire des tests manuels ? Beaucoup d'agences se contentent de lancer exactement ces fameux outils automatisés, de coller les logs dans un rapport type et de facturer ça comme un pentest. Demandez impérativement à l'agence le périmètre la méthodologie et le nombre d'heures d'analyse manuelle prévues.

Les clauses de sécurité des contrats grands comptes imposent généralement des tests réalisés par des auditeurs disposant d'une accréditation indépendante. Un rapport d'évaluation interne rédigé par vos propres employés n'atténuera pas votre responsabilité juridique en cas de fuite de données et pourrait vous exposer à des pénalités pour rupture de contrat.

Regardez le questionnaire de sécurité de votre client. S'il mentionne explicitement un pentest indépendant par un tiers, ne perdez pas votre temps avec votre propre outil. Négociez plutôt avec l'agence en limitant le nombre d'IP et de noms de domaine inclus dans le test pour tenter de descendre le prix autour de 4.000 GBP.

Ne découragez pas votre dév mais positionnez cet outil comme un filet de sécurité pendant la phase de dev. Si vous scannez en interne et corrigez les failles simples avant l'audit indépendant le rapport de l'agence ressortira propre et vous fournirez un document bien plus valorisant à votre client.

edit : j'ai écrit depuis mon téléphone, désolé pour les fautes.

enregistré.

Je ne peux pas totalement adhérer à cela. Une sauvegarde non testée n'est pas une sauvegarde.

Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé. J'espère que cela vous sera utile.

Je ne savais pas ça... Les gens défendent l'habitude pas le processus. bref la résistance vient de là.

Bon courage.

je suis entièrement d'accord. aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

j'espère que cela vous sera utile.

La réponse ci-dessus va droit au but. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

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

Nous avons vécu presque la même chose l'année dernière. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Quand on essaie de tout changer en même temps rien ne prend. C'est confirmé par l'expérience.

Je me permets une petite mise en garde. Essayer de faire cela seul est la voie la plus coûteuse.

Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion. Bien sûr, cela change si votre situation est différente.

Je suis intéressé.

Nous avons vécu presque la même chose l'année dernière. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Je me pose aussi la question.