Secu

Le Bug Bounty est un atout stratégique pour les RSSI

Par La rédaction, publié le 21 juillet 2020

Début juin, une étude menée par un acteur américain du Bug Bounty mettait en évidence les craintes des RSSI français face à ce modèle, expliquant que la moitié d’entre eux préfèrent risquer d’avoir des vulnérabilités dans leurs systèmes plutôt que de l’ouvrir à des hackers éthiques. De mon point de vue, après 18 mois d’utilisation en continu, les avantages du Bug Bounty effacent ces craintes, d’autant plus que celles-ci sont infondées.

Par François Chemin, RSSI (*)

Il me paraît d’autant plus important de clarifier les choses quand la moitié des répondants à cette même étude assurent passer trop de temps à chercher les failles, et ne pas être satisfaits des pentests. C’est justement dans cette situation que le Bug Bounty devient un atout stratégique pour l’entreprise, et une nécessité des développements agiles.

Pour notre Groupe, le Bug Bounty est aujourd’hui devenu un complément obligatoire. Évidemment, nous ne pouvons pas nous passer des pentests, tant pour des raisons légales que pour les quelques avantages qu’ils nous procurent. Toutefois, le Bug Bounty apporte des compléments dont nous ne pouvons désormais plus nous passer. Aujourd’hui, il nous a permis de devenir bien plus efficaces, non seulement dans la détection des failles, mais aussi dans leur traitement. Les systèmes que nous soumettons au Bug Bounty sont en effet testés en permanence par une grande variété de hackers éthiques, et donc d’approches. Nous ne sommes plus limités à des audits ponctuels qu’il faut organiser, planifier, et qui demandent parfois plusieurs mois de mise en place, et qui demandent des contre audits.

C’est bien simple : aujourd’hui, nous pouvons détecter et corriger des failles critiques sur les services que nous soumettons au Bug Bounty en moins de deux semaines, et avoir la confirmation de la correction du hacker. Avec un pentest, entre la planification, le choix de la date, etc., il nous fallait parfois deux mois pour être notifié d’une telle faille au lancement d’un nouveau service. D’expérience, le recours aux hackers éthiques permet de détecter plus de failles, et plus rapidement.
Nous avons pu constater à de nombreuses reprises que les hackers sont montés en compétences en 18 mois sur nos applications, ce qui n’est pas possible dans un pentest. De plus, nous n’avons plus de limitation en termes de nombre de sites à tester, car nous pouvons tester des éventails plus larges de endpoints. L’adhésion de nos développeurs a été plus rapide que prévu et a modernisé la vision de la sécurité de l’entreprise.

J’ai également vu que les répondants à l’étude craignaient de manquer de ressources pour se lancer dans le Bug Bounty. Tout dépend en réalité de la formule choisie. Nous avons pour notre part fait le choix d’un programme privé « managé » par YesWeHack. Nous bénéficions ainsi d’une personne dédiée qui s’assure de gérer la relation avec les hackers, de valider les bugs et vérifier la qualité des rapports, la reproductibilité des bugs, etc. Ce fonctionnement scalable, même s’il est évidemment plus onéreux, nous permet d’être plus libres et de ne pas avoir à mobiliser beaucoup de ressources internes pour gérer le Bug Bounty. Nous pouvons nous concentrer uniquement sur la correction des bugs, ce qui est in-fine le plus important.

Au-delà des questions de ressources, beaucoup de RSSI ont aussi manifesté des craintes au niveau des budgets à mettre en place pour le Bug Bounty.
Quand nous avons lancé notre Bug Bounty, nous avions nous aussi des questions quant à cet aspect. C’est pour cela que nous avons commencé doucement, et avons ouvert aux hackers des endpoints, qui avaient déjà été pentestés, et sur lesquels nous pensions qu’ils trouveraient peu de bugs. Et pourtant, sur ces périmètres restreints, plusieurs failles, même critiques, nous ont été remontées. Rien que cela a justifié l’investissement de départ. J’ajoute qu’il est facile de suivre la consommation de son Bug Bounty. Si jamais les budgets viennent à s’envoler, nous avons juste à appuyer sur le gros bouton rouge pour tout arrêter. En comparaison à des pentests, si nous voulions avoir la même couverture, nous devrions en organiser tous les trois mois, ce qui n’est évidemment plus du tout rentable.

Quant aux craintes liées au fait d’ouvrir ses systèmes à des « inconnus », nous avons fait le choix de travailler sur un Bug Bounty privé.
Les chercheurs qui testent nos applications sont loin d’être des inconnus et sont vérifiés par YesWeHack.
En 18 mois, nous n’avons d’ailleurs eu aucun comportement déviant ou problématique. Nous avons aussi pris certaines mesures au niveau du SoC. Il faut comprendre que les hackers attaquent nos systèmes avec des IP YesWeHack que nous connaissons et, même si les équipes de la sécurité gardent un œil dessus, elles ont pour directive de les laisser tester les systèmes. En revanche, si une IP inconnue venait à manifester des comportements potentiellement dangereux, elle serait immédiatement bannie.

Pour se rassurer, il y a bien des manières plus sûres que d’autres pour se lancer dans le Bug Bounty. En faisant le choix d’un programme privé, nous avons un contrôle permanent sur les hackers qui testent nos endpoints. En outre, comme je l’ai dit plus haut, nous avons fait le choix de commencer par des applications que nous pensions sûres à 100 %. Mais il a fallu qu’une montée de version ne soit pas faite correctement, ou qu’un patch ait été oublié, pour que les premières failles nous soient remontées, et ces dernières n’étaient pas mineures. Non seulement cette démarche progressive permet d’être très prudents dans la mise en place du Bug Bounty et de maîtriser ses budgets, mais en plus, elle met en évidence des failles là où nous étions persuadés de ne pas en trouver, ce qui valide, de fait, le bien-fondé de la stratégie pour l’ensemble de l’entreprise.
Quand le Bug Bounty permet de détecter une faille critique dans un système critique que tout le monde pensait sûr à 100%, immédiatement, les directions comprennent la valeur d’une telle démarche continue.

À mon sens, il n’y a pas de craintes à avoir quant au Bug Bounty. C’est un complément indispensable aux stratégies de sécurité traditionnelles à condition de bien s’y prendre.
Déjà, il faut sortir du Bug Bounty « marketing » où les entreprises annoncent des programmes uniquement pour faire de la pub.
Ensuite, il ne faut pas hésiter à y aller doucement, sur des systèmes estimés sûrs pour se rassurer, découvrir cet écosystème et généraliser à l’ensemble de ses systèmes.

Je comprends qu’il puisse y avoir des craintes au début. Même chez nous, quand nous avons commencé, beaucoup étaient inquiets, que ce soit dans les branches légales ou à la gestion des risques.
Aujourd’hui, le Bug Bounty est pourtant devenu une évidence même pour notre comité exécutif.
___________________

François Chemin est le pseudonyme d’un RSSI d’un grand groupe d’assurance européen bien réel.

A lire également :
Des entreprises encore trop frileuses face au Bug Bounty…