Decathlon allie PenTesting et Bug Bounty pour blinder ses applications

Le pentest, indispensable, mais pas suffisant

« Nous faisons fonctionner pentest et Bug Bounty en tandem. »

Pour s’assurer de la sécurité des applications développées par cette structure, l’équipe sécurité fait un usage extensif des tests d’intrusion – ou pentest, pour penetration test. Matthieu Vanoost, Security Manager chez Decathlon en charge de l’équipe SOC, DevSecOps et de la gestion de projets cyber, pointe néanmoins les limites de cette approche : « le pentest n’est clairement pas suffisant. Les prestataires spécialisés utilisent toujours les mêmes techniques d’attaque, les mêmes outils. Les résultats des pentests tendent à être identiques, avec les mêmes qualités et les mêmes défauts sur toutes les applications ».

Le responsable souligne que l’action des pentesters se concentre essentiellement sur la recherche des vulnérabilités techniques, alors que les hunters qui participent à un programme de Bug Bounty cherchent les failles sur un spectre beaucoup plus large, notamment dans les processus, la manière dont sont implémentées les applications.

Les deux approches s’avèrent donc complémentaires et Decathlon mène toujours des pentests sur ses applications avant de les soumettre à la sagacité des hackers.

Mathieu Bolla décrit le processus habituel : « nous faisons fonctionner pentest et Bug Bounty en tandem. Quand nous avons une application qui consiste en un front-end qui appelle des API, le pentester va être capable de tester une API enfouie dans le système d’information et qui n’est pas accessible depuis Internet. Il va nous remonter des vulnérabilités techniques. Le hunter, lui, n’a accès qu’au front, mais s’il arrive à exploiter toute la chaîne jusqu’à une API fautive, alors il peut faire apparaître les erreurs d’architecture, les erreurs de processus, etc. ». « C’est sur ces points que le hunter aurait une forte valeur ajoutée. Il va tirer profit de toutes petites choses dans plusieurs API pour constituer une grosse vulnérabilité qui peut conduire jusqu’à l’exécution de code à distance », conclut-il.

« Qui dit grandes ambitions dit niveau de sécurité au plus haut niveau, et le Bug Bounty est sans doute le meilleur moyen pour nous confronter nous-mêmes à l’exercice en demandant à quelqu’un d’essayer d'entrer. »

Autre différence de taille des deux approches, le pentest est aligné avec le calendrier de release des nouvelles versions. Un pentest peut être lancé lors de la phase d’UAT (User Acceptance Testing, tests de validation utilisateur). L’équipe peut alors prévoir des ressources pour corriger les vulnérabilités éventuelles.

Le Bug Bounty se conçoit plutôt comme du test en continu, en marge du calendrier de release. Le hunter peut intervenir à n’importe quel moment ; peu lui importe le pays et les spécificités de l’application. Tout ce qui entre dans le scope défini dans le programme est matière à trouver une vulnérabilité. « Chaque approche a ses avantages et ses inconvénients. Le pentest va plus en profondeur dans le SI, le Bug Bounty permet de travailler sur le monde réel, sur l’exposition réelle de l’application », résume Mathieu Bolla.

Une mise en place qui demande une organisation adaptée

Decathlon a recours aux programmes Bug Bounty avec YesWeHack, le spécialiste français de cette approche. Pour Matthieu Vanoost, le premier challenge auquel l’équipe sécurité a dû faire face est interne, c’est la validation du contrat de Bug Bounty : « expliquer à un juriste ce qu’est un Bug Bounty, c’est compliqué, car il n’y a pas de garanties contractuelles sur la façon dont cela va se passer. C’est un vrai travail de sensibilisation à mener auprès des juristes afin de leur expliquer pourquoi nous souhaitons faire un Bug Bounty, l’aspect communautaire d’une plateforme de Bug Bounty, le fait que les personnes sélectionnées sont bien identifiées et que celles-ci sont notées sur la plateforme au même titre que nous le sommes. Il faut aussi expliquer que ces campagnes peuvent être de type fermé. L’application ne sera pas ouverte à des milliers de personnes d’un seul coup ».

L’autre point clé fut de convaincre les équipes IT que le pentest n’est pas suffisant. Lancer un programme de Bug Bounty peut être perçu comme une remise en question pour certains qui estiment que leur application n’a aucune vulnérabilité. « Il faut bien expliquer aux équipes que le but du Bug Bounty n’est pas de pointer du doigt une mauvaise implémentation, mais bien de faire progresser tout le monde », explique le responsable.

Outre cet effort d’explication en interne, Matthieu Vanoost considère que se lancer dans une approche Bug Bounty implique de s’organiser en interne pour y faire face : « nous avons dédié une personne de l’équipe sécurité qui travaille sur le Bug Bounty, les relations avec YesWeHack, le lancement des programmes. Il faut pouvoir assurer une bonne qualité et pouvoir se montrer exigeants, notamment ne pas se limiter à des périmètres trop étroits ».

Un programme de Bug Bounty implique de mettre en face les ressources nécessaires pour faire face aux retours des hunters. Ceux-ci ne sont payés qu’à partir du moment où la vulnérabilité qu’ils ont trouvée est validée par l’entreprise. Si les vulnérabilités non validées s’accumulent et que le délai de paiement devient trop important, l’image de l’entreprise va en souffrir et aucun hacker chevronné ne voudra participer à ses programmes. 

« Quand nous lançons un programme, des développeurs sont prêts à intervenir rapidement pour apporter des correctifs dans les délais que nous nous sommes fixés. »

« Il faut être capable de valider le plus rapidement possible les vulnérabilités », explique Matthieu Vanoost. « Nous nous sommes fixé des objectifs : à chaque nouveau programme, une vulnérabilité doit pouvoir être qualifiée dans la journée, à savoir si elle est bien présente et quel est son degré de sévérité, afin de donner la bonne prime à celui qui l’a découverte ».

De même, si la vulnérabilité n’est pas corrigée rapidement, le hunter n’aura qu’une piètre image de l’entreprise. Decathlon a mis en place une organisation pour corriger ces vulnérabilités au plus vite. « Quand nous lançons un programme, des développeurs sont prêts à intervenir rapidement pour apporter des correctifs dans les délais que nous nous sommes fixés. Pour les vulnérabilités les plus critiques, nous nous sommes donné un engagement de correction en 24 h. Cela implique un travail qui n’est pas neutre pour les équipes ».

Le responsable souligne le besoin de préparer tous ces aspects afin d’initier la campagne ; notamment bien établir le scope exact du test, les équipes internes qui seront impliquées et le nombre de hunters qui seront intégrés au programme. Decathlon a commencé petit, puis a fait grossir peu à peu ses programmes.

Enfin, un dernier point important à définir avant de se lancer dans le Bug Bounty : bien définir le modèle économique interne de l’opération. Dans le cas de Decathlon, l’équipe sécurité paye l’accès à la plateforme YesWeHack, puis chaque application, chaque Feature Team paye les primes qui sont versées aux hunters pour les vulnérabilités découvertes dans leur domaine.

Une difficulté évidente provient de l’interpénétration des applications modernes et donc la répartition des primes entre toutes les équipes affectées. « Le volet économique était une crainte initiale des équipes avec un coût variable en fonction des vulnérabilités remontées, alors que le pentest a un coût fixe », explique le responsable. « Avec le recul, il s’avère que le coût n’est pas véritablement un problème. Un programme de Bug Bounty représente un coût comparable à celui d’un gros pentest ». 

Decathlon a lancé avec succès un Bug Bounty en live sur le FIC 2022

Fort de cette expérience de plusieurs années de Bug Bounty, Decathlon a tenté une grande première lors de l’édition 2022 du FIC, celle de lancer un Bug Bounty en direct, lors de la manifestation. Des hackers de niveau expert ont été invités à pirater le périmètre Decathlon.tn, le site tunisien de l’enseigne qui présente l’intérêt d’être développé par l’équipe canadienne et d’être une plateforme très interconnectée et très distribuée, avec de multiples niveaux de support.

« Nous avons invité une cinquantaine de hackers, 26 d’entre eux ont publié des rapports. Côté défense, nous avions amené deux Security Officer, plusieurs Tech Lead, les Product Manager des deux grosses plateformes, des membres des équipes support et Ops afin de réagir vite et bien. L’opération s’est déroulée comme n’importe quel Bug Bounty. C’était à la fois une belle opportunité de communiquer, de montrer ce qu’est réellement un Bug Bounty, et de montrer comment nous testons nos sites ».

L’événement était public, et l’opération a été jugée très intéressante en termes de marque employeur ainsi que de recrutement. Sur le plan cybersécurité, elle a permis de découvrir des vulnérabilités qui n’avaient pas été imaginées par l’équipe de sécurité. « L’opération a été plus coûteuse qu’un Bug Bounty “classique”, car nous avions des hackers de très haut niveau. Néanmoins, nous avons estimé que l’opération avait été profitable et moins coûteuse que si nous avions mené des pentests sur chacune des plateformes intégrées ». Faire asseoir les membres de l’équipe SOC à la même table que les hackers est aussi un moyen d’améliorer ses défenses.

« N’importe quel hacker inscrit sur YesWeHack pourra tester nos applications. Cela permettra de nous ouvrir à plus de nationalités. »

Le recours au Bug Bounty étant jugé très fructueux en interne, Matthieu Vanoost estime que la prochaine étape sera de proposer des programmes de Bug Bounty publics et de ne plus se contenter de programmes fermés. « N’importe quel hacker inscrit sur YesWeHack pourra tester nos applications. Cela permettra de nous ouvrir à plus de nationalités ».

Une autre évolution envisagée sera de fusionner certains des programmes, une séparation par Business Unit ayant de moins en moins de sens pour des applications sur lesquelles plusieurs BU jouent un rôle.

Enfin, l’équipe informatique songe à un « Star Program », c’est-à-dire à ouvrir des programmes sur un scope beaucoup plus large de type « *.decathlon.* ». L’enseigne ne compte pas moins de 11 000 noms de domaines déposés et lancer les hunters pourrait bien faire remonter des vulnérabilités encore cachées.

Enfin, le responsable aimerait bien pouvoir guider un peu plus les hackers dans leurs recherches, notamment leur donner des informations sur les nouvelles Features livrées dans le périmètre de recherche, ou des éléments techniques sur le backend. L’idée est d’orienter leurs recherches et leur permettre d’aller encore plus loin dans leur recherche de la vulnérabilité qui a échappé à tous les pentests.

Propos recueillis lors d’un atelier organisé lors de l’édition 2022 des Assises de la Sécurité.