On nous demande de faire un test d'intrusion — c'est quoi concrètement et en a-t-on vraiment besoin ?

Les grands comptes de la distribution ont une peur bleue du risque lié aux sous-traitants. Si vos serveurs hébergent les données de leurs boutiques ou de leur chiffre d'affaires, ils doivent pouvoir se justifier auprès de leur conseil d'administration. N'essayez surtout pas de leur refiler un simple scan de vulnérabilités automatique en guise de pentest : leurs experts sécu le repèreront dès la première page et vous ruinerez la vente.

On a fait notre premier pentest l'automne dernier pour un logiciel logistique de taille comparable. L'audit a duré 4 jours ouvrés pour 3 200 GBP. Ils ont déniché 6 failles, dont une critique. On pensait notre code en béton, mais un simple oubli dans les en-têtes HTTP révélait la version exacte de notre base de données. On a corrigé ça en une semaine, et le client a signé le contrat dès réception du rapport validé.

Faites très attention lors de la définition du périmètre dans le contrat. N'incluez pas l'hébergeur de votre infrastructure cloud, limitez-vous uniquement au code que vous avez développé, aux mécanismes d'autorisation et aux API. Sinon, ils vont vouloir scanner les services du fournisseur cloud, ce qui doublera la durée du test et votre budget.

Ne sautez pas sur les premiers devis envoyés par les boîtes de sécu. Beaucoup d'agences demandent des sommes folles comme 10.000 GBP pour au final laisser tourner des outils automatisés et s'arrêter là. Demandez 2 ou 3 devis différents à des experts seniors certifiés indépendants ou travaillant en petite structure. Assurez-vous bien que le rapport sera rédigé selon des méthodologies reconnues à l'international.

Pour un contrat qui va rapporter 52.000 GBP par an, un coût de test d'environ 3.000 GBP est clairement un coût d'acquisition client qui vaut le coup d'être payé. En plus, une fois ce rapport en main, vous pourrez le présenter comme gage de confiance à tous les autres clients grands comptes avec qui vous négocierez au cours des 12 prochains mois.

qu'est-ce qui se passe si des failles sont trouvées pendant le test et qu'on ne peut pas les corriger tout de suite ? la boîte de sécu envoie le rapport directement au cliennt ou elle nous le donne d'abord à nous ?

Correction : je me suis trompé sur le chiffre, c'était un peu plus bas.

Le déroulement classique se fait en 4 étapes : 1) Définition du périmètre et signature d'un accord de confidentialité, 2) Simulation d'attaque sur un environnement de test (serveur clone sans données réelles), 3) Remise d'un rapport intermédiaire listant les vulnérabilités à votre équipe et phase de correction, 4) Vérification des correctifs et rédaction du rapport final propre à destination de l'entreprise cliente.

Je vais raconter ce qui m'est arrivé ça pourrait vous servir. La plupart des incidents ne viennent pas d'une faille mais d'un mot de passe divulgué.

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

Comment avez-vous résolu ce point ? Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Avant de décider, regardez quelles données vous avez en main. Voilà, désolé si je me suis étendu.

Je trouve difficile d'être aussi catégorique côté exemple test intrusion. Si vous grondez les fausses alertes, plus personne ne signalera rien.

À votre place, j'irais par cette voie.

C'est noté merci.

Je me pose aussi la question. Quand on décide sans mesurer, on revient toujours au même point.

La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort. Je suis aussi curieux de savoir si d'autres font autrement.

Merci pour votre retour. Si c'est une première, commencez petit, l'échelle viendra plus tard.

Tous ceux qui se pressent sur exemple test intrusion se heurtent au même obstacle. C'est confirmé par l'expérience.

Je suis d'accord en partie, pas en partie. Si vous obtenez trois réponses différentes sur un sujet la question est mal posée.

Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard. Bien sûr, cela change si votre situation est différente.

Je partage mon expérience. Tous ceux qui se pressent sur exemple test intrusion se heurtent au même obstacle.

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

Je suis d'accord, j'aimerais même souligner ce point. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

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

Beau travail.

La réponse ci-dessus va droit au but. Lors de la prise de décision écrivez aussi le pire scénario pas seulement le meilleur.

Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine. C'est confirmé par l'expérience.