Pourquoi la Poste a besoin d’un programme bug bounty

Cette semaine, la Poste a lancé son programme bug bounty public. Sandro Nafzger, responsable du programme bug bounty, explique pourquoi il n’a fallu que quelques heures pour réaliser que la collaboration avec des hackers éthiques était indispensable, le programme ayant cependant nécessité deux années pour pouvoir être mis en place.

Sandro Nafzger
Blog
Head of Bug Bounty Sandro Nafzger

Section Contenu riche

Lorsque nous avons dépassé nos craintes et décidé de tenter l’expérience de la collaboration avec des hackers éthiques, nous nous sommes immédiatement rendus à l’évidence: il était indispensable d’avoir recours à un programme bug bounty! Le budget alloué à ce projet n’a pas été suffisant pour les six semaines prévues mais pour juste un peu moins de quatre heures, ce qui était également un très bon signe. Mais commençons par le commencement...

Au printemps 2019, la Poste avait effectué pour la première fois un test public d’intrusion et publié également le code source du système de vote électronique d’alors. Ce qui a donné lieu à de vifs débats, notamment dans les médias. Ceci pourrait faire penser que, s’étant alors brûlé les doigts avec cette approche d’examen public, la Poste déciderait de se tenir bien à l’écart de tout projet similaire. Mais c’est exactement le contraire qui s’est produit. Car cet exemple le montre: la méthode a fonctionné et les erreurs critiques ont pu être détectées et résolues. Ainsi le système concerné et l’organisation s’y rattachant peuvent encore être améliorés.

C’est alors que s’est posée la question de la pertinence pour la Poste dans son ensemble d’une collaboration avec une communauté mondiale d’experts en sécurité informatique dans le cadre d’un programme bug bounty. Notre instinct nous poussait dans cette direction, mais nous ne pouvions nous appuyer que sur l’unique expérience menée avec le vote électronique et sur un maigre savoir-faire. Après concertation avec le CISO Poste, nous avons donc lancé une étude de trois mois avec le soutien d’une équipe interdisciplinaire composée de trois experts en sécurité, d’un responsable de projet, d’un avocat et d’un expert en communication. Nous avons ainsi examiné le concept du «bug bounty» sous toutes les coutures et sommes arrivés à la conclusion que ce programme pouvait s’avérer crucial pour la Poste, qu’il était possible d’en bénéficier largement, que les coûts étaient supportables et que nous venions donc de trouver une solution pragmatique au problème de la faisabilité. Afin de vérifier si ces théories tenaient la route, Information Security Poste a ensuite décidé de mener une démonstration de faisabilité de six semaines.

Tout a démarré le lundi 21 octobre à 11h00: nous avons appuyé sur le bouton de démarrage de notre tout premier programme bug bounty privé. Pour commencer, nous n’avons autorisé que cinq hackers éthiques à «pirater» environ dix systèmes informatiques bien déterminés et à les examiner minutieusement à la recherche de failles de sécurité. Et voilà qu’en moins d’une heure, nous avons reçu un premier rapport au sujet d’une faille de sécurité hautement critique. Et ce ne fut pas le seul, loin de là. Mais comment était-ce possible? Nous n’avions pourtant soumis au test que des services en ligne établis de longue date, dont la sécurité était régulièrement vérifiée au moyen de méthodes de test éprouvées.

Pour l’ensemble de la démonstration de faisabilité, qui était censée durer six semaines, nous avions mis de côté la somme totale de CHF 25 000.− pour le versement de récompenses. À 15h00, autrement dit quatre heures à peine après le lancement du test de six semaines, nous avions déjà épuisé notre budget. Cela posait-il problème? Non, bien au contraire: nous avons immédiatement réalisé que cette nouvelle méthode de test était bien plus efficace et cruciale que ce que nous avions pu imaginer, et qu’elle représentait une opportunité unique pour la Poste. Les résultats obtenus en l’espace de seulement quelques heures étaient si déterminants que le CISO Poste a alors augmenté à plusieurs reprises notre budget et laissé le test se dérouler pendant en tout cinq semaines. Nous avons pu tester tout particulièrement l’interaction entre les hackers et les personnes chargées du développement. Nous avons ainsi constaté que cette nouvelle collaboration nous permettait de résoudre rapidement les erreurs trouvées et que le courant est tout de suite bien passé entre les deux groupes différents. Ce test nous a permis de déceler et d’éliminer 130 failles de sécurité, certaines étant banales, d’autres se révélant critiques. Nous avons versé environ CHF 150 000.– de récompenses.

Il n’a ainsi fallu que quelques heures pour résoudre la question de la nécessité réelle d’un programme bug bounty. À l’aide d’un tel programme, il est en effet possible de déceler des failles de sécurité que toutes les autres méthodes de test avaient jusque là été incapables de mettre au jour, et ce de manière particulièrement efficace.

À l’issue du premier test de faisabilité, nous avons cherché le moyen d’introduire progressivement cette méthode nouvelle et disruptive et de l’établir au niveau du groupe, sans pour autant nous submerger. En effet, une chose était claire: un programme bug bounty qui ne serait pas limité par certaines restrictions mènerait à la découverte de centaines de nouvelles vulnérabilités en l’espace de quelques jours, ce qui saturerait complètement notre organisation. Cela était contraire au but recherché. C’est ainsi qu’est né notre modèle d’échelonnement du programme bug bounty.

Première étape pour un service en ligne: l’Incubator

Notre modèle d’échelonnement se compose de trois niveaux de maturité atteignables par un service en ligne. Tout d’abord, lorsqu’une application arrive pour la première fois dans notre programme bug bounty, elle commence toujours à l’étape du «Custom Incubator», un programme bug bounty limité dans le temps où œuvrent entre cinq et cinquante hackers éthiques et pour lequel les récompenses sont relativement peu élevées. À cette étape, les premières heures ou les premiers jours suffisent pour déceler et signaler les principaux problèmes de sécurité. Cela indique non seulement le degré de maturité en matière de sécurité du produit ou du service testé, mais aussi l’agilité et l’adéquation de l’organisation et de l’équipe impliquées. 

Passée l’étape du «Custom Incubator», deux scénarios sont ensuite possibles. Dans l’idéal, le système testé peut alors être directement transféré vers le programme permanent et privé appelé «Private Main». Ce qui compte, ce n’est pas tant le nombre de vulnérabilités découvertes que la manière dont l’équipe en charge du système va gérer celles-ci. Pour certaines équipes, il est normal de recevoir quotidiennement de nouvelles données, de les classer par ordre de priorité selon des règles claires et de les corriger lors de sprints réguliers. Pour d’autres, cette manière de procéder requérant une certaine agilité reste encore un défi. Généralement, après l’étape du Custom Incubator, ces équipes ont besoin d’une pause pour pouvoir mieux s’organiser en interne et corriger les vulnérabilités qui ont été décelées.

Avec l’étape dite «Private Main», la Poste s’est engagée depuis le mois de mai 2020 dans un programme bug bounty permanent et privé. De nouveaux services en ligne sont continuellement ajoutés à ce programme et minutieusement testés par plusieurs centaines de hackers éthiques avant d’être transférés vers le programme bug bounty «Public Main». Celui-ci vient d’être lancé et il est désormais disponible pour les 23 000 hackers inscrits.

Ce modèle composé de trois niveaux nous a permis d’acquérir et de consolider progressivement la maturité nécessaire à la gestion des programmes bug bounty, afin d’exploiter un programme à l’échelle du groupe procurant une grande satisfaction à tous les participants.

C’est la condition préalable à l’amélioration continue de la majorité des produits numériques de la Poste – plusieurs centaines de systèmes informatiques – à l’aide du programme bug bounty. 

Pour résumer, collaborer avec des hackers éthiques demande de surmonter ses craintes, mais s’avère en contrepartie extrêmement bénéfique, de précieux enseignements et de nouvelles possibilités d’amélioration en résultant quasiment chaque jour. De plus, une telle collaboration favorise l’établissement d’une culture de l’apprentissage positive et agile, dont toute l’organisation tire profit. Il n’existe pas de programme bug bounty parfait. Mais en commençant modestement et en développant le programme de façon continue, nous sommes sur la bonne voie.

rédigé par

Sandro Nafzger

Responsable du programme bug bounty