Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Bug Bounty Nuit du Hack 2017 – Orange, un an après

Bug Bounty Nuit du Hack 2017 – Orange, un an après
2017-06-302017-06-30actualités et événementsfr
Pour la seconde année consécutive, le groupe Orange a participé au Bug Bounty organisé lors de la quinzième édition de la Nuit du Hack. Voici le feedback très terrain de Georgian MIHAILA, ingénieur sécurité et expert sur le programme de Bug Bounty d’Orange.
Publié le 30 Juin 2017 par Jean-François Audenard dans actualités et événements
Bug Bounty Nuit du Hack 2017

Pour la seconde année consécutive, le groupe Orange a participé au Bug Bounty organisé lors de la quinzième édition de la Nuit du Hack. Belle occasion de faire le point sur l’intérêt pour une grande entreprise de mettre en place un programme de Bug Bounty et de partager ensemble quelques conseils pour aller plus vite. Voici le feedback très terrain de Georgian MIHAILA, ingénieur sécurité et expert sur le programme de Bug Bounty d’Orange.

Salut Georgian. Peux-tu te présenter en quelques mots et nous expliquer comment est né le sujet Bug Bounty au sein d’Orange ?

Georgian MIHAILA – Salut Jean-François. Je suis ingénieur sécurité au sein de la DSI Orange France. Avant j’étais aussi chez Orange, mais dans les équipes d’OrangeLabs sur la R&D en sécurité. A cette époque, l’idée de lancer un Bug Bounty était un sujet de discussion qui revenait souvent entre collègues. Mais il y a six ans, ce sujet était peut-être un peu trop en avance. Quand je suis arrivé à la DSI d’Orange France, l’idée avait fait son chemin et les responsables de la sécurité des services web en production étaient clairement favorables à l’idée d’un Bug Bounty.

Peux-tu revenir sur le premier Bug Bounty du Groupe Orange et nous expliquer comment il est né,  quelles ont été les difficultés rencontrées ?

Comme tu le sais, le premier Bug Bounty du groupe Orange a été lancé en juin 2016 lors de la Nuit du Hack. C’est avec l’aide de la BountyFactory que nous avons commencé. Notre choix de travailler avec eux a été guidé par le fait qu’en plus de l’infrastructure technique nécessaire pour canaliser les remontées, faciliter le triage et rémunérer les Hunters (les personnes participant au Bug Bounty), leur offre vient avec une communauté particulièrement riche de Hunters. C’est peut-être ce dernier point qui est le plus important pour une réussite dans la durée.

Lors de cette première incarnation du programme de Bug Bounty, nous avons fait le choix de mettre dans le périmètre le service d’annuaire « 118712.fr ». Le plus compliqué a été de convaincre les personnes en charge du service de participer car c'était une prise de risque inédite au sein d’Orange. Effectivement, il y avait la crainte de lancer une initiative qui pouvait laisser un impact négatif en termes d’image. Il y avait aussi des aprioris quant au niveau de sécurité réel de la plateforme et d’éventuelles craintes de la part des personnes qui en avait la charge si un nombre trop important de failles venait à être trouvées à l’occasion du Bug Bounty.

In fine, tout s’est bien passé, mais comme il s’agissait d’une « toute première fois » il était normal d’avoir plus de craintes que de raison. Après, nous avons beaucoup appris. Le périmètre de premier Bug Bounty était peut-être un peu trop restreint et certains Hunters se sont sentis un peu à l’étroit sur le 118712.fr. Encore une fois, c’était une première, donc nous y sommes allés doucement.

Dans tous les cas, je tiens à saluer les responsables du service qui ont osé le pari de l’innovation et qui nous ont accordé leur confiance pour amorcer le programme de Bug Bounty avec succès.

Quid du nombre de failles remontées lors de ce premier Bug Bounty ? Comment a été gérée la communication a posteriori ? 

Lors de ce premier Bug Bounty, sur le périmètre du service 118712.fr, nous avons eu 15 rapports sur une durée d’exposition de 15 heures. Sur les 15 rapports (ou « remontées ») 9 failles ont été confirmées et donc rémunérées. Les 6 autres étaient des « duplicates », c'est-à-dire des failles déjà remontées précédemment par un autre Hunter.

Sur les 9 vulnérabilités remontées, deux d’entre elles concernaient des failles qui étaient connues de nos équipes, mais dont les correctifs n’étaient pas encore déployés. Cette première instance de notre Bug Bounty nous a donc permis d’identifier – et donc de corriger après-coup - 7 nouvelles vulnérabilités en 15 heures.

A noter que 2 autres failles que nous connaissions aussi n’ont pas été découvertes par les Hunters alors qu’elles n’étaient pas non plus particulièrement complexes.

En parallèle du traitement des vulnérabilités identifiées par les Hunters, nous avons débriefé, dès le lundi matin, les personnes du marketing produit ainsi que le directeur technique sur le déroulement du Bug Bounty et de ses résultats. Clairement, ils ont été agréablement surpris de voir l’absence de « bad buzz » et, contre toute attente, la participation d’Orange à un Bug Bounty a même été saluée.

Après ce premier Bug Bounty qui a été concluant, y a-t-il eu une suite ? 

Nous avons lancé courant janvier 2017 d’autres instances de Bug Bounty, encore une fois en mode privé, sur 6 périmètres différents. Les périmètres couvraient des services grand public et aussi des clients professionnels. Le service 118712.fr était l’un des 6 périmètres, mais pour le reste c’est « motus et bouche cousue ! ».

Pourquoi avoir fait le choix, encore une fois, du mode « privé » ?

Tout d’abord parce qu’un programme privé est plus facile à organiser. Dans un grand Groupe comme Orange, il y a beaucoup d’équipes impliquées dans chacun des périmètres impliqués dans le Bug Bounty. De plus Le choix d’un mode « privé » et borné dans le temps et a permis de rassurer les personnes concernées quant aux risques de « bad buzz ».

En quoi le traitement des remontées issues d’un Bug Bounty est-il différent des failles identifiées lors d’un test de pénétration classique ?

D’un côté, les choses sont similaires, car dans les deux cas il est nécessaire d’analyser les remontées, de les qualifier pour ensuite les corriger. Ce qui change avec un Bug Bounty c’est la rapidité avec laquelle il est nécessaire que ce cycle se déroule.

Dans le cas des remontées faites par les Hunters, nous avons fait le choix de les rétribuer dès lors que la faille était confirmée par nos équipes, sans attendre le déploiement effectif du correctif. Il est important de dire rapidement aux Hunters si leurs remontées sont qualifiées ou si il s’agit de duplicates. Le principe est de conserver une bonne dynamique avec des équipes très réactives, ce qui n’est pas forcément nécessaire dans le cadre de tests de pénétration classiques. Cette rapidité doit être la même pour des failles qui ne sont pas forcément très critiques. En tout cas, pour les équipes qui ont fait l’expérience d’un Bug Bounty, les retours sont positifs, car cela leur permet de s’améliorer. 

D’autres conseils à partager avec les personnes qui souhaiteraient aussi mettre en place un programme de Bug Bounty ? 

La création de la "fiche programme" qui va définir le périmètre du Bug Bounty et ses règles est un élément clef. La création de cette fiche doit être faite non seulement avec les personnes en charge de la sécurité des plateformes techniques, mais aussi avec les directions Marketing, ou support client. Elle permet de définir clairement le périmètre et les conditions du Bug Bounty, en interne ou  pour les Hunters qui participeront.

En interne, mon conseil est d’avoir un kit de communication pour expliquer ce qu’est un Bug Bounty, ses bénéfices, comment il se déroule, etc. Cela permet de partager un même niveau d’information tout en définissant un vocabulaire commun.

Au-delà de l’intérêt évident d’identifier et de corriger des failles de sécurité, quels sont les autres bénéfices d’un Bug Bounty ? 

Un Bug Bounty permet la création de canaux de communication plus francs et directs entre les différentes équipes. Les remontées sont autant d’exemples très concrets et pratiques qui permettront ensuite d’alimenter les actions de sensibilisation ou de formation. Par exemple, certains contenus spécifiques seront destinés aux équipes en charge du développement logiciel, d’autres aux exploitants des plateformes de services.

De plus, la pratique des Bug Bounty permet aux personnes d’aborder la gestion de risques dans leurs projets avec plus de recul pour une prise de risque plus mesurée ou équilibrée. Clairement, une équipe projet qui a fait l’expérience d’un Bug Bounty sera mieux préparée à gérer en amont ou en aval la sécurité de ses activités.

Last but not least, les équipes de sécurité gagnent en expérience en s’inspirant des découvertes et méthodes utilisées par les hunters.

Georgian, encore merci pour ce partage d’expérience 

Tout le plaisir a été pour moi - à bientôt ! 

 

Pour aller plus loin

Une approche globale de la sécurité
Nuit Du Hack 2016 – Orange lance son Bug Bounty
Baromètre Cybersécurité 2017 : où en est l’industrie française ?

 

Changer d'affichage