Accompagner nos clients pas à pas dans leur démarche de Bug Bounty

Categories
Best Practices

Si vous nous demandiez en quoi YesWeHack diffère des autres plateformes, nous vous répondrions sans hésiter que c’est par la qualité de notre support. Accompagner au mieux nos clients fait partie de nos valeurs depuis notre création. Nous savons que le lancement d’un programme de Bug Bounty peut représenter un vrai défi pour les responsables sécurité. C’est souvent un pari qu’ils font avec leur hiérarchie, et la grande majorité n’ont jamais travaillé sur le sujet.

C’est pourquoi, chez YesWeHack, nous assistons nos clients dès le départ, quel que soit le type de programme de Bug Bounty (privé ou public). Notre équipe support est à leurs côtés pour les guider et les conseiller, à chaque étape, afin de garantir le succès de leur programme et ainsi répondre à leurs besoins.

Pour détailler la manière dont nous accompagnons nos clients, nous nous sommes entretenus avec notre Head of Customer Success, Selim Jaafar. Nous avons discuté avec lui de son rôle chez YesWeHack et des meilleures pratiques à adopter en matière de sécurité crowdsourcée.

Bonjour Selim, peux-tu nous expliquer rapidement ton rôle au sein de YesWeHack ?

Hey !

Je suis Head of Customer Success chez YesWeHack. Mon rôle consiste à assurer la réussite du parcours de nos clients lorsqu’ils implémentent un programme de Bug Bounty, ce qui implique bien sûr certains aspects techniques, fonctionnels, organisationnels et humains. Mon équipe et moi apportons notre expertise et notre expérience à nos clients – ils ont presque toujours besoin de conseils et d’accompagnement lorsqu’il s’agit de mettre en œuvre et de déployer leurs programmes de Bug Bounty.  

Les entreprises ont généralement peu d’expérience sur la mise en œuvre d’un programme de Bug Bounty. Contrairement à nous, qui pouvons nous appuyer sur les retours de centaines d’entreprises dont les programmes, les objectifs, les approches et les budgets varient. Nous pouvons donc facilement identifier et anticiper les “pièges” potentiels, partager les meilleures pratiques et aider nos clients à se projeter dans l’univers du Bug Bounty. Nous sommes également proches de la communauté des chercheurs. Ainsi, nous pouvons répondre à diverses questions concernant leur éthique, leur manière de travailler ou encore la façon d’interagir et de collaborer avec eux dans le cadre d’un programme de Bug Bounty.

De plus, le lancement d’un programme via la plateforme YesWeHack permet de bénéficier d’un ensemble très complet de fonctionnalités, d’intégrations avec des systèmes tiers, d’indicateurs et d’autres outils à disposition de nos clients. Les aider à maîtriser la plateforme, à en tirer le meilleur parti et à rendre le processus encore plus efficace, est naturellement une partie essentielle de mon travail. A ce titre, il est nécessaire de toujours se remettre en question et de recueillir les réactions et les souhaits de nos clients, dans le but de s’améliorer continuellement et de répondre au mieux à leurs besoins.

Par ailleurs, je supervise notre équipe interne de “triage” pour les clients qui souscrivent à ce service supplémentaire. Étant le point d’entrée des clients, je peux transférer leurs instructions à l’équipe de triage afin de mettre en place des flux de travail appropriés et de créer le service de triage le plus efficace et le plus complet possible. Un triage fluide est l’une des clés du succès d’un programme de Bug Bounty, et l’une des forces de notre plateforme.

En définitive, mon rôle est de permettre aux clients, avec un budget donné et des ressources forcément limitées, de tirer le meilleur parti du modèle Bug Bounty, tout en évitant certains faux pas. Y parvenir nécessite un accompagnement constant : embarquer les clients sur la plateforme et les familiariser avec le modèle, lancer leur premier programme, le faire évoluer, l’animer et déployer le programme de Bug Bounty à plus grande échelle, étape par étape, sur le long terme.

🎯 A terme, mon but serait de faciliter l’adoption du Bug Bounty par les clients au sein de leur entreprise.

Pourrais-tu nous parler des principales étapes à mener avant le lancement d’un programme de Bug Bounty ?

Indiquez le(s) périmètre(s) qui doit (doivent) être testé(s) en premier lieu. Supposons qu’il s’agisse de votre premier programme de Bug Bounty. Dans ce cas, il y a un équilibre à trouver : assez étendu pour être intéressant et aboutir à des résultats concrets, mais assez restreint pour rester gérable. Certains préféreront tester en premier lieu leurs applications les plus critiques, tandis que d’autres testeront des applications moins sensibles. Il n’y a pas de mauvais choix ici ; cela dépend de vos objectifs et de vos ressources en matière de sécurité mais également de ce que vous essayez de prouver ou d’améliorer par ces premières itérations.

Définissez et préparez les modalités de contrôle. Boîte noire ou boîte grise ? Sur un environnement de production ou un environnement dédié ? Comment les chercheurs peuvent-ils accéder à mes périmètres ? Ce genre de sujets s’accompagne souvent de problématiques qu’il vaut mieux identifier dès les premières étapes de votre projet.

🎯 Astuce : plus vous donnerez de latitude aux hackers, plus ils seront engagés, plus les résultats seront exhaustifs et intéressants.

Déterminez un budget et fixez les priorités. Bien entendu, plus le budget est élevé, meilleurs seront les résultats. Néanmoins, vous pouvez avoir de bons résultats avec un budget minimal, à condition de fixer vos priorités et de vous concentrer sur ce qui importe le plus, que ce soit en termes de périmètre ou de type de vulnérabilités.

Identifiez les parties prenantes, répartissez les rôles et attribuez les responsabilités. Les programmes de Bug Bounty impliquent souvent un large éventail d’acteurs et de parties prenantes, principalement les équipes en charge du développement, de la sécurité et de l’exploitation. Veillez à identifier tous ceux qui jouent un rôle direct dans le programme et à leur accorder l’accès approprié au sein de la plateforme, et donc, à faire respecter les rôles et les responsabilités pour une meilleure gestion des rapports. D’autre part, il n’est jamais trop tôt pour informer les autres parties concernées du prochain programme de Bug Bounty et des tests en direct.

Rédigez votre programme. C’est dans la définition de votre programme que vos moyens, vos objectifs et vos contraintes se préciseront, à travers les périmètres, les récompenses et les règles que vous mettrez en place.

Définition du programme ✔️

Répartition des rôles ✔️

Liste des chercheurs ✔️

Environnement test ✔️

Processus et workflows clairement définis ✔️

Il est maintenant temps de mettre le programme en ligne, félicitations ! o/

🎯 Astuce : mieux vaut éviter de lancer un nouveau programme un vendredi, histoire de passer un bon week-end 😉

Quelles sont les choses à faire et à éviter lors de la rédaction d’un programme ?

L’ambiguïté est votre ennemi n°1. Faites attention à la façon dont vous définissez le périmètre, les vulnérabilités admissibles et les règles d’éligibilité de votre programme. Ne laissez pas trop de place à l’interprétation (des deux côtés, c’est-à-dire à la fois pour les chercheurs et les responsables du programme) car cela pourrait être frustrant, trompeur ou contre-productif.

Une fois vos objectifs clairement identifiés, la rédaction du programme doit être une transposition de ceux-ci, en termes de :

  • Périmètre : ce qui doit être testé ;
  • Règles : ce qui peut être fait ou non lorsque les périmètres sont testés ;
  • Récompenses : ce à quoi on peut s’attendre en soumettant un rapport valide.

Pour compléter, vous pouvez ajouter quelques détails sur le fonctionnement de l’application et sur la manière dont les chercheurs doivent procéder pour accéder au programme (création de comptes, environnement de tests, etc.). Tout ce qui pourrait aider les chercheurs à se mettre correctement au travail pour que vous obteniez les résultats escomptés, rien de moins.

Ne négligez pas les détails. C’est la raison pour laquelle nous examinons systématiquement toutes les créations et mises à jour de programmes – pour nous assurer que la description correspond aux objectifs et aux attentes du client. Tout comme nous enrichissons régulièrement notre formulaire de création de programme et nos modèles pour guider les clients dans ces étapes décisives.

Très bien, maintenant que le programme est en place, comment s’assurer de son bon fonctionnement ?

La plupart du temps, le travail se fait du côté des chercheurs, qui identifient les vulnérabilités, et du côté des clients, qui les corrigent. Mais comme je le disais plus haut, nous offrons un support personnalisé à nos clients, et cela s’accompagne de réunions régulières, pour faire le point sur :

  • La charge de travail des équipes internes : êtes-vous à l’aise avec le flux actuel de rapports soumis ?
  • Les résultats vs. les objectifs : les derniers rapports reçus étaient-ils pertinents et utiles ?
  • Les possibilités d’amélioration ou de renforcement : voulez-vous aller plus loin ? Souhaitez-vous vous recentrer sur un aspect en particulier ?

En fonction des retours et des attentes du client, je peux faire quelques suggestions et recommandations, sur la direction à donner au programme :

  • Inviter d’autres chercheurs ;
  • Introduire de nouveaux périmètres ;
  • Passer de la boîte noire à la boîte grise ;
  • Augmenter la grille de récompense ;
  • “Wait and see”.

À tout moment, je dois m’assurer que le programme reste sous contrôle (en ce qui concerne le budget, la charge de travail, le rattrapage des retards, etc.) tout en apportant de la valeur et des résultats significatifs.

Quels sont les meilleurs moyens d’éviter que les chercheurs ne se désintéressent d’un programme ?

Plutôt que de faire la liste de ce qui pourrait ne pas marcher ou de ce qu’il faut éviter, je mettrais plutôt l’accent sur ce qu’il faut faire pour mettre toutes les chances de votre côté :

  • Soyez juste : essayez d’adopter le point de vue des chercheurs et gardez à l’esprit le temps, les compétences et les efforts qu’ils consacrent à votre collaboration.
  • Soyez de bonne foi : faites un effort pour comprendre et appliquer les meilleures pratiques en matière de traitement des rapports des chercheurs (par exemple, s’agit-il vraiment d’un doublon?). Faire preuve d’équité ne signifie pas être trop généreux ; cela signifie simplement être juste.
  • Faites preuve de transparence : cela s’applique pour de nombreuses situations et de nombreux sujets. Le Bug Bounty est une approche collaborative : plus vous partagez d’informations avec les chercheurs, plus ils seront impliqués. Par exemple, lorsque vous réduisez l’impact d’une vulnérabilité, vous pouvez avoir de très bonnes raisons de le faire, que le chercheur ne comprendra que si vous les lui expliquez, même brièvement.
  • Optez pour l’interaction : une fois encore, c’est inhérent au modèle de collaboration ; les interactions directes vous aideront souvent à aller au fond des choses. Si vous n’êtes pas sûr de comprendre l’impact d’une vulnérabilité, ou ses implications techniques, n’hésitez pas à demander. Le partage des connaissances est inscrit dans l’ADN des chercheurs.
  • Soyez créatif : dans vos règles, votre ton ou en créant de nouveaux défis au sein du programme lui-même ; il existe de nombreuses façons de se différencier ou d’expérimenter grâce à un Bug Bounty.
  • Montrez-vous reconnaissant : il est courant de penser que les chasseurs de bugs ne s’intéressent qu’aux primes. Soyons honnêtes, c’est une grande motivation et une attente légitime, compte tenu du travail et des efforts fournis. Mais à long terme, les chercheurs auront tendance à se concentrer sur des programmes où ils se sentent appréciés et utiles. Après tout, c’est une question d’interactions humaines.
  • Et, plus important encore, restez cool, faire du Bug Bounty doit être amusant avant tout !

Comment gères-tu la relation entre les clients et les chercheurs ?

La plupart du temps, je laisse aux clients et aux chercheurs le soin de gérer leurs interactions 😊

Cependant, il est important de s’assurer que les deux composantes de cet écosystème (organisations et chercheurs) apprennent à se comprendre. Les deux parties ont leurs propres mentalités ou points de vue sur la manière dont un programme doit être géré, dont un rapport doit être trié ou récompensé, etc. Et ce n’est pas du tout un problème. Il en résulte une grande diversité et des débats enrichissants, tout aussi instructifs pour les deux parties, tant que chacun garde l’esprit ouvert.

C’est une source d’inspiration pour moi, et pour nous en tant que plateforme de Bug Bounty, de rassembler ces différents univers et de créer des synergies. Nous ne prenons pas parti, et nous ne le ferons jamais. Le Bug Bounty est un écosystème riche et dynamique que les plateformes, les organisations et les chercheurs doivent partager et améliorer ensemble !

Merci, Selim !

Vous êtes intéressé par une démo ou vous voulez savoir comment mettre en place un programme de Bug Bounty dans votre organisation ? Prenez contact avec notre équipe👇

À propos de YesWeHack :

Créé en 2013, YesWeHack est la première plateforme de Bug Bounty et de VDP en Europe.

YesWeHack propose aux entreprises une approche disruptive de la cybersécurité, le Bug Bounty, modèle qui récompense les chercheurs à la vulnérabilité. Notre plateforme connecte plus de 21 000 experts en cybersécurité (« hackers éthiques ») répartis dans 170 pays avec des organisations de toutes tailles et de tous secteurs pour sécuriser leurs périmètres exposés et rechercher les vulnérabilités (bugs) de leurs sites web, applications mobiles, infrastructures et objets connectés.

YesWeHack gère des programmes privés (seulement accessibles sur invitation) et des programmes publics pour des centaines d’organisations à travers le monde, en conformité avec les réglementations européennes les plus strictes.

En plus de sa plateforme de Bug Bounty, YesWeHack offre également : un soutien à la création d’une politique de divulgation des vulnérabilités (VDP), une plateforme d’apprentissage pour les hackers éthiques appelée DOJO et une plateforme de formation pour les institutions éducatives, YesWeHackEDU.