« Open source vs. cybersécurité - La Robe Numérique » : différence entre les versions
(→13’ 10) |
|||
Ligne 84 : | Ligne 84 : | ||
==13’ 10== | ==13’ 10== | ||
<b>Oriana Labruyère : </b>Du coup, | <b>Oriana Labruyère : </b>Du coup, pourquoi avez-vous fait ce choix ? La première question c’est pourquoi choisir une communauté fermée, parce que là, ce ne sont pas des programmes publics, tout le monde ne peut venir taper le programme Dolibarr. La première question c’est pourquoi faire le choix de cette forme de confidentialité, finalement, donc du programme fermé ? Pourquoi faire ce choix alors même qu’il y a une grosse communauté derrière Dolibarr, c’est, je pense, une des communautés les plus importantes du Libre, sur un <em>open source</em>. Pourquoi faire ce choix ? | ||
<b>Laurent Destailleur : </b>La question a le mérite d’être posée. On n’a pas fait le choix exclusif de prendre une plateforme de <em>bug bounty</em>. On a aussi un système, le système communautaire, qui marche très bien, donc un système de déclaration de bugs qui est fait par la communauté, qui est le même système, finalement, que le système de déclaration de bugs non sécurisé, qui sont des bugs fonctionnels ou applicatifs. Ce système-là fonctionne très bien, le problème c’est qu’il a ses limites dans le sens où il y a pas d’incitation financière et trouver des failles de sécurité, quand elles sont faciles à trouver, il n’y a pas forcément besoin d’incitation, mais si on veut bien sécuriser, il faut passer énormément de temps pour trouver les bugs et ça devient très compliqué, il faut des spécialistes. Le métier de la sécurité, le hacking aujourd’hui, ce n’est plus comme on le faisait dans les années 80 : on était informaticien, on pouvait faire du hacking sur son temps libre parce que c’était presque une option. Aujourd’hui, c’est devenu un métier à part entière et si on n’exerce pas ce métier à temps plein, on n’est pas un bon hacker, voire on ne l’est pas du tout. | |||
<b>Oriana Labruyère : </b>C’est même clairement un métier à part entière des deux côtés de la frontière. | |||
<b>Laurent Destailleur : </b>Yogosha fait ce métier de trouver comment hacker grâce à son vivier de hackers, la <em>red team</em>. Et puis, côté de l’applicatif, par exemple Dolibarr, on va avoir des <em>blue teams</em>, donc des gens qui vont travailler pour sécuriser et faire en sorte qu’on ne soit pas attaqués. Il y a donc ces deux facettes.<br/> | |||
Sur Dolibarr, on a effectivement l’aspect communautaire, mais on a vu qu’il avait ses limites, et aujourd’hui, penser que l’on peut sécuriser sans faire appel à un programme de <em>bug bounty</em> c’est que l’on ne connaît pas le monde de la sécurité. | |||
<b>Oriana Labruyère : </b>Qu’on est hyper optimiste ! | |||
<b>Laurent Destailleur : </b>J’irais jusqu’à dire qu’on est prétentieux ! On peut être expert en sécurité, on ne peut pas être expert dans tous les domaines de la sécurité. Si on connaît très bien comment sécuriser une appli web, on ne va pas forcément connaître tous les trucs et astuces sur l’aspect système ou sur d’autres aspects. Il y a plein de pans et chaque acteur est même spécialisé dans un domaine en particulier. On ne peut pas être spécialisé dans tout. | |||
<b>Manon Desplat : </b>Je me permets une toute petite incision. Les hackers avec lesquels je travaille, ceux qui font exclusivement de la sécurité offensive, donc soit du <em>pentest</em>, du <em>bug bounty</em>, etc., se prennent souvent un mois, dans l’année, durant lequel ils ne font que de la formation. C’est pour rejoindre le propos de Laurent comme quoi tout évolue très vite, surtout en matière de sécurité, toutes les technologies qui ressortent, etc. Donc, oui, effectivement ce serait prétentieux de penser qu’on a un savoir universel. | |||
<b>Oriana Labruyère : </b>Je comprends. Une question me vient. On entend souvent et je l’entends aussi beaucoup dans les collectivités territoriales, sécuriser c’est dépenser, la sécurité c’est cher, donc moi, dans le monde du Libre, je suis obligée de me poser la question : comment finance-t-on un programme de <em>bug bounty</em> quand, par nature, ce n’est pas gratuit, mais, quand même, ce n’est pas très cher. Par rapport à Dolibarr, je comprends que vous fassiez ce choix-là, du coup, ça veut dire que financièrement on donne un <em>award</em>, d’un côté on va on va donner une prime, une récompense aux hackers. Comment gère-t-on cette manne financière quand on a, finalement, des solutions qui sont qui sont peu onéreuses à l’achat ? | |||
<b>Laurent Destailleur : </b>C’est une difficulté qui se comprend. Tu évoques la difficulté des projets <em>open source</em> de passer la barrière, on va dire, du mode communautaire pour se sécuriser pour rentrer dans le monde du <em>pentest</em> financé. Pour les gros projets, il n’y a pas trop de difficultés, on va rentrer dans le même mode que celui d’un logiciel propriétaire où le gros projet va avoir des finances. C’est le cas du projet Dolibarr, on a des revenus grâce à différents modèles, il y a différentes sources de revenus sur le projet, ce qui nous permet de faire appel à ces programmes qui nécessitent rémunération.<br/> | |||
Par contre, il y a effectivement une problématique pour d’autres projets, les plus petits, qui vont avoir des difficultés pour passer cette barrière financière. Là il y a plusieurs solutions, il y a eu, par exemple, la plateforme Hunter qui proposait gratuitement : la plateforme Hunter mettait en place une plateforme de <em>bug bounty</em> qui était financée par des dons mis en commun et qui ensuite rétribuaient à la fois la <em>red team</em> et la <em>blue team</em>. Ce modèle-là a fonctionné quelque temps, mais on voit qu’il a ses limites puisque maintenant ils ont limité ça uniquement aux projets qui sont dans le domaine de la ??? [18 min 48]. Pour les autres projets, si on n’est plus dans ce domaine-là, il y a effectivement cette difficulté et aujourd’hui c’est compliqué. Il faut avoir des équipes qui soient vraiment compétentes pour pouvoir réussir à le faire ou trouver des fonds. | |||
<b>Oriana Labruyère : </b>Si je comprends bien, et par rapport à ce qu’on disait, je renvoie les auditeurs au premier épisode, par rapport à la nature même du Libre, finalement les failles de sécurité qui sont trouvées, qui sont financées notamment dans le cadre de ce programme de <em>bug bounty</em> vont bénéficier à l’ensemble des utilisateurs de Dolibarr, y compris les sociétés qui ont les moyens de payer, mais qui font le choix du Libre, et c’est super, mais qui, du coup bénéficient, par voie de conséquence, d’un niveau de sécurité qui, en tout cas financièrement, est assumé pas vraiment par elles. | |||
<b>Laurent Destailleur : </b>C’est un autre mode. Il y a effectivement un autre mode, que je n’ai pas encore évoqué, pour sécuriser les programmes <em>open source</em>, qui s’applique à tous, aussi bien aux gros qu’aux petits. Souvent, ce sont les utilisateurs eux-mêmes qui font appel à des sociétés de recherche en informatique, qui elles vont aller rechercher, parce que le client utilise ce logiciel, elles ont des responsabilités, elles font appel à des sous-traitants pour trouver des failles et ces sous-traitants, dans une idée éthique, ne vont pas se contenter de remonter la faille à leurs clients, avec la correction, ils vont aussi la communiquer au projet <em>open source</em>. Donc, des projets <em>open source</em> vont bénéficier, parce que c’est un projet ouvert. C’est ce qui fait que chaque chercheur peut aller chercher les failles et les remonter au projet d’origine. | |||
<b>Oriana Labruyère : </b>Du coup, c’est quand même un enjeu. L’aspect financier est quand même un véritable enjeu. | |||
<b>Laurent Destailleur : </b>Quand on passe par ce biais-là, le projet <em>open source</em> n’a pas de contraintes financières. Par contre, il y a effectivement un système financier entre un client et la société informatique qui va faire le <em>bug bounty</em>. Et il y en a dans le monde aujourd’hui, beaucoup de sociétés se créent et sont spécialisées là-dedans. | |||
<b>Oriana Labruyère : </b>Finalement, lors du choix du Libre sur l’aspect cybersécurité, on peut se poser cette question de savoir à quel programme est attaché le logiciel. | |||
<b>Laurent Destailleur : </b>Il faut se renseigner et challenger le projet même : que faites-vous en termes de sécurité, quelle est votre équipe, quel est votre <em>blue team</em>, quelles démarches avez-vous ? Est-ce que vous faites appel à une société, ou pas, où est-ce que vous reposez ? Il faut effectivement se renseigner. Si c’est un point de vue important et ça doit être, aujourd’hui, un point de vue important dans tout projet informatique, numérique, il faut se poser cette question et faire ses recherches. | |||
<b>Oriana Labruyère : </b>Je me disais que pendant l’épisode avec ??? [22 min 10] je n’ai pas posé cette question-là, chez Yogosha, voyez-vous une évolution de ces typologies clients et voyez-vous de plus en plus de communautés du Libre venir vers vous ? Est-ce qu’il y a eu un changement, une évolution des pratiques ? | |||
<b>Manon Desplat : </b>J’avoue que je ne saurais pas répondre en pourcentage combien d’éditeurs privés on peut avoir contre les éditeurs de solutions libres, mais je pense que le maître-mot qu’on doit retenir de tout cela, c’est le complément. Il y a l’aspect communautaire qui existe, et qui est déjà très efficace, malgré son pendant ; quand je parlais du sujet de cet épisode à un de mes collègues, il m’ a dit « ce qui est bénéfique dans l'<em>open source</em> c’est qu’il y a un peu la politique du venez comme vous êtes ». « Venez comme vous êtes » offre l’opportunité à des personnes, à des hackers éthiques, de venir découvrir les vulnérabilités et améliorer le produit, mais aussi à des acteurs un peu plus malveillants et, forcément, peut générer ce genre de problème. D’où le fait d’avoir un programme de <em>bug bounty</em> en parallèle, en complément, qui peut permettent d’améliorer le produit, puisque cette fois-ci, on vérifie les typologies de profils qui actent sur ce genre de programme et on est sûr de garantir une certaine activité, puisque j’imagine qu’il y a possiblement des temps mous aussi au sein de la communauté, où il y a un petit peu moins de vulnérabilités qui sont remontées. Sur le <em>bug bounty</em>, on fait en sorte que les incitations monétaires, ou même l’intérêt qu’on peut porter à un programme, soient continues de sorte de pouvoir accéder à cette sécurité. | |||
<b>Oriana Labruyère : </b>Un maintien de la sécurité à un niveau plutôt intéressant pour veiller à ce qu’il n’y ait pas tout de suite une faille. | |||
<b>Laurent Destailleur : </b>Une campagne de <em>bug bounty</em> ce n’est pas une campagne, il faut que ce soit continu, parce que les failles arrivent aussi avec les évolutions et il y a aussi les évolutions technologiques | |||
<b>Manon Desplat : </b>Un programme de <em>bug bounty</em>, ce ne s’est pas figé du tout dans le temps, c’est édité à chaque implémentation d’une nouvelle fonctionnalité, à chaque mise à jour, donc ça garantie quand même un certain intérêt pour les acteurs qui sont invités sur le programme, « il y aura peut-être des trucs à trouver ! » | |||
<b>Laurent Destailleur : </b>Il faut voir que les hackers utilisent beaucoup l'<em>open source</em>, des outils qui sont créés aussi par des projets <em>open source</em>, c’est même souvent l'<em>open source</em> qui tire ces outils et ces outils évoluent très vite, s’améliorent très vite, donc, quelque part, les <em>red teams</em> deviennent de plus en plus performantes et vont jusqu’à trouver des choses que l’on ne trouvait pas il y a cinq/dix ans dans le même programme, des choses qui existaient déjà, mais qui n’ont pas forcément été trouvées, du fait de la maturité, de la complexité. | |||
<b>Manon Desplat : </b>Ça rejoint totalement l’évolution dont on parlait il y a quelques minutes. | |||
<b>Oriana Labruyère : </b>Finalement, si on fait un parallèle avec le logiciel propriétaire, le <em>bug bounty</em> fonctionnera de la même manière, ça nous permet d’arriver au même résultat, sauf que, dans un cas, on a accès à l’information par une plus grande communauté et, dans l’autre cas, on va, finalement, n’avoir que l’éditeur qui aura le résultat et qui, à date, on peut le dire, n’a pas l’obligation de remonter sa vulnérabilité, quoique dans les contrats, etc., en tout cas on attend. | |||
<b>Laurent Destailleur : </b>C’est ça. On va dire que l’<em>open source</em> a des choses en plus par rapport au propriétaire. | |||
<b>Oriana Labruyère : </b>Dans cette obligation d’information. | |||
<b>Laurent Destailleur : </b>Pas une obligation légale, mais une obligation communautaire qui s’exerce. S’il y a une faille de sécurité dans un projet <em>open source</em>, que vous ne la corrigez pas, il y a la communauté, il y a des gens dans communauté qui vont lever les drapeaux. Il y a une pression du public qui fait qu’on est obligé d’y répondre. | |||
<b>Oriana Labruyère : </b>OK. C’est pas mal la pression du public !<br/> | |||
En préparant nos échanges, on a aussi évoqué la question des parties prenantes et de la méthodologie EBIOS. Qui a envie de répondre à cet aspect, qui est la question, en fait, de la responsabilité du tiers dans la sécurité et dans le maintien de la sécurité ? | |||
==26’ 45== | |||
<b>Laurent Destailleur : </b>Déjà, |
Version du 28 août 2024 à 11:39
Titre : Open source vs. cybersécurité
Intervenant·es : Manon Desplat - Laurent Destailleur - Oriana Labruyère
Lieu : Podcast La Robe Numérique
Date : 19 avril 2024
Durée : 42 min 23
Licence de la transcription : Verbatim
Illustration : À prévoir
NB : Transcription réalisée par nos soins, fidèle aux propos des intervenant·es mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.
Transcription
Oriana Labruyère : Chères amies auditrices et auditeurs, bienvenue dans ce nouvel épisode de La Robe Numérique que vous retrouvez, pour cette nouvelle saison, en version vidéo et en version audio. Merci beaucoup d’être avec nous. Nous allons continuer notre série sur le Libre. Aujourd’hui nous allons aborder un sujet qui est « Le Libre est-il sécurisé ? », c’est la première question parce qu’il y a beaucoup trop d’idées reçues sur le Libre.
J’ai avec moi deux invités. Laurent tu étais déjà là sur le premier épisode, je vais me permettre de rappeler, donc Laurent Destailleurs, tu étais et tu es toujours CEO et CTO de DoliCloud, tu es chef de projet Dolibarr, et tu es là parce que tu es aussi un ancien hacker éthique.
Laurent Destailleur : Ancien hacker, aujourd’hui hacker éthique.
Oriana Labruyère : D’accord. Attention le code pénal n’est pas loin !
Nous avons aussi, comme invitée aujourd’hui, Manon Desplat qui est Security program manager chez Yogosha.
Pour commencer, avant qu’on rentre dans le vif du sujet, je vais vous demander de présenter les entreprises pour lesquelles vous travaillez, ça permet aussi de poser le sujet et de faire le lien avec la cybersécurité et l'open source. Manon, est-ce que tu peux nous présenter Yogosha.
Manon Desplat : Bien sûr. Yogosha ce sont deux choses. Yogosha, c’est d’abord une plateforme qui permet de centraliser toutes les opérations de sécurité offensive. On propose à la fois du bug bounty, sur lequel on pourra revenir durant cet épisode puisque Laurent participe à ce genre de programme, on propose aussi des pentests, du VDP [Vulnerability Disclosure Program], tout ce qui va être remontée de vulnérabilités sauvages, des solutions forensiques, etc. Tout est donc centralisé sur cette plateforme, c’est vraiment un produit qu’on met à disposition de nos clients. Yogosha est aussi une communauté de hackers éthiques, terme évoqué par Laurent il y a quelques secondes. On a à peu près 800 personnes qui travaillent à la fois sur nos programmes de bug bounty, mais aussi pour un pool un petit peu plus restreint sur les thématiques de pentests, les missions de pentest
Oriana Labruyère : Merci Manon. Laurent est-ce que tu peux nous présenter DoliCloud et puis ton positionnement vis-à-vis de Dolibarr ?
Laurent Destailleur : DoliCloud est une société qui propose Dolibarr en SaaS, je pense que ça suffit comme information. Dolibarr, c’est plus intéressant. Dolibarr est un logiciel de gestion d’entreprise qui est assez complet, puisqu’on essaye de toucher tous les besoins d’une entreprise, du CRM, de VRP, de la RH, etc. C’est un logiciel qui est pas mal implanté dans les entreprises et qui est un outil critique pour les entreprises. Aujourd’hui j’assure, on va dire, le rôle de valider les évolutions qui sont faites dans le projet Dolibarr.
Oriana Labruyère : Le Libre, ce n’est pas sécurisé. Vrai ou faux ?
Laurent Destailleur : Si je me permets, il va déjà falloir définir ce que c’est que sécuriser. Il y a 15/20 ans, on pensait que la sécurité informatique, puisque c’est de cela qu’on parle, la sécurité vis-à-vis du numérique, qu’il fallait que ce soit secret, c’est-à-dire que pour que ce soit sécurisé, on rendait les choses secrètes, on ne les documentait pas, on ne donnait pas d’informations sur le secret de fabrication, etc. On s’est rendu compte que ça avait un gros problème : un, ça n’arrêtait pas les hackers, puisque les hackers avaient les capacités à faire du reverse engineering, donc la capacité à comprendre, sans documentation, comment ça fonctionne et à trouver les failles, donc ça ne les arrêtait pas, par contre ça empêchait les améliorations et les corrections. Avec un autre système, le système ouvert donc le logiciel libre ou open source, le fait de documenter et de rendre public le secret de fabrication, donc le code d’un programme informatique, on s’est rendu compte, vis-à-vis des hackers, qu’il y avait toujours cette capacité à pirater, par contre, vis-à-vis de tout le reste de la population, les chercheurs en sécurité, etc., on facilitait leur travail pour trouver où étaient les failles et on avait donc une capacité à résoudre, à sécuriser et avoir l’information des endroits où sont les failles et à les corriger beaucoup plus rapidement et de manière beaucoup plus efficace qu’avec un modèle fermé. Donc, par rapport à la question, si on la prend dans sa globalité, est-il moins sécurisé ?, non. Aujourd’hui, on a compris qu’il faut que le modèle soit ouvert pour que ce soit plus sécurisé.
Oriana Labruyère : Finalement c’est non et c’est peut-être même plus sécurisé que le propriétaire.
Laurent Destailleur : Aujourd’hui, c’est clairement une affirmation qu’on peut faire sans trop de difficultés. On sait qu’il vaut mieux un modèle ouvert, avec beaucoup de chercheurs qui vont analyser pour sécuriser le système, qu’un modèle fermé où on attend que les failles tombent.
L’autre problématique que l’on a aussi c’est que, dans un modèle propriétaire, quand une faille est tombée, l’éditeur ne va pas forcément la communiquer. Aujourd’hui, pour rendre cela obligatoire, les réglementations évoluent et c’est très bien, mais on n’a jamais cette certitude. Alors qu’avec le Libre, celui qui va trouver la faille va rentrer dans le système communautaire du développement du logiciel et va publier cette faille dans le système communautaire, donc, quelque part, il met la pression et rend obligatoire la correction vis-à-vis de l’équipe qui gère le programme. Là encore, ce côté public fait qu’il y a également une meilleure inertie à la correction que l’on constate dans les logiciels libres et open source par rapport à certains logiciels propriétaires où on a des failles qui sont quasiment éternelles, certains décideurs vont même jusqu’à dire que ce sont des features, it's not a bug, it's a feature.
Manon Desplat : On retrouve cet aspect communautaire de manière très générale en informatique et dans la cybersécurité et ça rejoint beaucoup la mentalité hacker, si je peux simplifier de cette manière-là, ça demande aussi des efforts de la part, je ne sais plus exactement le terme, lorsqu’au sein de la communauté il y a des merge requests qui sont faites pour améliorer un produit, pour indiquer qu’une faille a été découverte. Des cyberattaques ont pu être orchestrées aussi de cette manière : on va demander une merge request et, finalement, ça va permettre de mener une attaque et d’avoir accès aux backdoors parce que l’implémentation était finalement quelque chose de malveillant. Donc, ça demande beaucoup d’efforts, de la même manière qu’un logiciel privé va devoir faire des efforts de sécurité ; quelque chose qui est accessible en open source nécessite aussi des efforts de sécurité et de vigilance aussi à ce moment-là. L’aspect communautaire est très bénéfique, comme Laurent l’a indiqué, pour qu’il y ait cette collaboration.
Laurent Destailleur : Parce que les efforts vont être répartis sur beaucoup de personnes là où, pour un propriétaire, ça va être uniquement sur l’équipe de l’éditeur.
Oriana Labruyère : Ce que vous dites c’est que, finalement, le savoir c’est le pouvoir. Une fois qu’on a l’information, on a le pouvoir de corriger et, en l’occurrence, lorsqu’on est sur du Libre, on a une plus grande communauté qui va travailler sur la correction de cette vulnérabilité identifiée, alors que dans le cadre d’un propriétaire, finalement on s’en remet déjà à ce que la vulnérabilité soit effectivement remontée par l’éditeur et à l’intervention de l’éditeur, puisque, par définition, dans le propriétaire on n’a pas accès au code et on ne peut pas modifier soi-même la vulnérabilité au niveau du code.
Laurent Destailleur : Je modérerais. Quand tu dis qu’on a une plus grande capacité à corriger, oui pour certains projets open source, pas pour d’autres. Il y a quand même certains projets open source qui ont des petites communautés et qui n’auront pas de bonne réactivité. Donc attention aux projets que vous choisissez, prenez plutôt déposer des projets qui ont une grande communauté pour bénéficier de cette capacité à corriger rapidement les failles de sécurité, par rapport à des petits projets qui seraient unipersonnels où là, forcément, on aurait plutôt le travers inverse, on aura une réactivité qui sera moins bonne.
Oriana Labruyère : Ça veut dire que dans le cadre où on a un projet unipersonnel avec une toute petite communauté, voire personne, finalement on s’en remet à des tiers qui permettent de faire des audits de vulnérabilité et une surveillance de ce code de manière un peu dynamique, du coup on corrige, on pallie au manque de communauté ; on peut dire ça.
Laurent Destailleur : Tout à fait, c’est la force du Libre : on peut effectivement pallier une faible communauté en faisant appel à un tiers.
Oriana Labruyère : On peut donc que si le Libre c’est plutôt sécurisé, voire c’est sécurisé, on peut dire que ce n’est pas moins sécurisé que le logiciel propriétaire, du coup, on peut dire que le logiciel propriétaire n’est pas une garantie de sécurité non plus, notamment en cybersécurité. Est-ce qu’on est tous d’accord avec ça ?
Laurent Destailleur : C’est clair ! Beaucoup d’exemples montrent que des failles de sécurité connues, en tout cas du monde des hackers mais pas forcément du grand public, et connues de l’éditeur restent ouvertes très longtemps. Ce sont des choses que l’on ne verra pas, ou très peu, dans des logiciels open source parce qu’à partir du moment où la faille est connue, il va y avoir quelqu’un, dans la communauté pour aller la corriger.
Oriana Labruyère : Est-ce que, finalement – ça revient sur cette question, mais on peut l’aborder différemment – le Libre ne va pas rendre plus vulnérable ? Tout à l’heure, en introduction, vous parliez de Yogosha et Dolibarr, est-ce que vous pouvez expliquer comment et pourquoi ?, parce que soit la vulnérabilité est soit dans le code, dès sa création soit ce sont les évolutions qui vont engendrer une vulnérabilité, l’existence de cette vulnérabilité. Comment travaillez-vous ensemble, pour rendre le cloud hyper safe au quotidien ?, pour bien démontrer qu’n peut faire du Libre super sécurisé. Est-ce que tu peux parler de la plateforme et de la façon dont vous bossez ensemble ?
Manon Desplat : Bien sûr. Dolibarr a programme de bug bounty sur la plateforme Yogosha. Tu me corrigeras s je dis une erreur, on va dire que c’est une sorte de complément de l’aspect communautaire qu’on peut retrouver dans l'open source. Avec le programme de bug bounty, il y a un aspect quand même un peu plus incitatif avec des rémunérations financières. Il y a quatre niveaux de rémunération qu’on peut trouver sur un programme de bug bounty en fonction de la criticité de la faille qui a été trouvée et c’est alimenté par les dons qui sont qui sont faits à Dolibarr, si je ne dis pas de bêtises.
Laurent Destailleur : Ce sont les fonds de Dolibarr. Dolibaar a plusieurs sources de fonds.
Oriana Labruyère : Petite incise pour rappeler ce qu’est le bug bounty, qui, du coup, permet à des hackers qui sont payés pour cela, d’aller rechercher des failles de sécurité qui ont différentes criticités, qui vont documenter ces failles, puisqu’il ne s’agit pas juste de la trouver, il faut aussi la documenter et apporter, potentiellement, des éléments de réponse à cette faille. En fait, on a un award qui sera financier, en fonction du nombre de failles, de la criticité de la faille, donc de la difficulté : plus c’est difficile, plus les hackers sont payés cher, évidemment, puisque plus la faille est potentiellement critique. Je peux vous renvoyer à un épisode de La Robe Numérique, Yes We Hack, puisqu’on n’a pas encore eu Yogosha, mais ça viendra. Incise terminée, je vous laisse continuer, mais je pense que c’était important de repréciser ce qu’est le bug bounty.
Manon Desplat : C’est vrai que j’aurais dû commencer par là, sur le programme de bug bounty. On invite des hunters à participer parce que, chez Yogosha, nous sommes sur des programmes qui sont fermés, donc c’est nous qui décidons quels hunters peuvent hunter, hacker, chasser.
Oriana Labruyère : Ce sont des chasseurs de primes numériques
Manon Desplat : Des chasseurs de primes, exactement ça. Sur ces programmes fermés, ils sont donc invités à rechercher des failles sur un asset bien précis, l’asset étant le programme de Dolibarr dans ce cas précis. Ils ont effectivement la possibilité d’expliquer à la fois la vulnérabilité qu’ils ont trouvée, c’est obligatoire, et, dans un deuxième temps, sur leur rapport de vulnérabilité, ils passent du temps à expliquer leur méthodologie. Ce n’est donc pas simplement une indication qu’un bug existe, c’est vraiment une sorte de pédagogie qui est mise en place pour que, de l’autre côté, côté client disons, les équipes puissent être réactives et puissent corriger la faille. En fait, on veut vraiment, avec du bug bounty, avoir un impact sur les systèmes de sécurité de nos clients. Et la troisième partie, toujours dans un aspect pédagogique, on propose des options de remédiation.
13’ 10
Oriana Labruyère : Du coup, pourquoi avez-vous fait ce choix ? La première question c’est pourquoi choisir une communauté fermée, parce que là, ce ne sont pas des programmes publics, tout le monde ne peut venir taper le programme Dolibarr. La première question c’est pourquoi faire le choix de cette forme de confidentialité, finalement, donc du programme fermé ? Pourquoi faire ce choix alors même qu’il y a une grosse communauté derrière Dolibarr, c’est, je pense, une des communautés les plus importantes du Libre, sur un open source. Pourquoi faire ce choix ?
Laurent Destailleur : La question a le mérite d’être posée. On n’a pas fait le choix exclusif de prendre une plateforme de bug bounty. On a aussi un système, le système communautaire, qui marche très bien, donc un système de déclaration de bugs qui est fait par la communauté, qui est le même système, finalement, que le système de déclaration de bugs non sécurisé, qui sont des bugs fonctionnels ou applicatifs. Ce système-là fonctionne très bien, le problème c’est qu’il a ses limites dans le sens où il y a pas d’incitation financière et trouver des failles de sécurité, quand elles sont faciles à trouver, il n’y a pas forcément besoin d’incitation, mais si on veut bien sécuriser, il faut passer énormément de temps pour trouver les bugs et ça devient très compliqué, il faut des spécialistes. Le métier de la sécurité, le hacking aujourd’hui, ce n’est plus comme on le faisait dans les années 80 : on était informaticien, on pouvait faire du hacking sur son temps libre parce que c’était presque une option. Aujourd’hui, c’est devenu un métier à part entière et si on n’exerce pas ce métier à temps plein, on n’est pas un bon hacker, voire on ne l’est pas du tout.
Oriana Labruyère : C’est même clairement un métier à part entière des deux côtés de la frontière.
Laurent Destailleur : Yogosha fait ce métier de trouver comment hacker grâce à son vivier de hackers, la red team. Et puis, côté de l’applicatif, par exemple Dolibarr, on va avoir des blue teams, donc des gens qui vont travailler pour sécuriser et faire en sorte qu’on ne soit pas attaqués. Il y a donc ces deux facettes.
Sur Dolibarr, on a effectivement l’aspect communautaire, mais on a vu qu’il avait ses limites, et aujourd’hui, penser que l’on peut sécuriser sans faire appel à un programme de bug bounty c’est que l’on ne connaît pas le monde de la sécurité.
Oriana Labruyère : Qu’on est hyper optimiste !
Laurent Destailleur : J’irais jusqu’à dire qu’on est prétentieux ! On peut être expert en sécurité, on ne peut pas être expert dans tous les domaines de la sécurité. Si on connaît très bien comment sécuriser une appli web, on ne va pas forcément connaître tous les trucs et astuces sur l’aspect système ou sur d’autres aspects. Il y a plein de pans et chaque acteur est même spécialisé dans un domaine en particulier. On ne peut pas être spécialisé dans tout.
Manon Desplat : Je me permets une toute petite incision. Les hackers avec lesquels je travaille, ceux qui font exclusivement de la sécurité offensive, donc soit du pentest, du bug bounty, etc., se prennent souvent un mois, dans l’année, durant lequel ils ne font que de la formation. C’est pour rejoindre le propos de Laurent comme quoi tout évolue très vite, surtout en matière de sécurité, toutes les technologies qui ressortent, etc. Donc, oui, effectivement ce serait prétentieux de penser qu’on a un savoir universel.
Oriana Labruyère : Je comprends. Une question me vient. On entend souvent et je l’entends aussi beaucoup dans les collectivités territoriales, sécuriser c’est dépenser, la sécurité c’est cher, donc moi, dans le monde du Libre, je suis obligée de me poser la question : comment finance-t-on un programme de bug bounty quand, par nature, ce n’est pas gratuit, mais, quand même, ce n’est pas très cher. Par rapport à Dolibarr, je comprends que vous fassiez ce choix-là, du coup, ça veut dire que financièrement on donne un award, d’un côté on va on va donner une prime, une récompense aux hackers. Comment gère-t-on cette manne financière quand on a, finalement, des solutions qui sont qui sont peu onéreuses à l’achat ?
Laurent Destailleur : C’est une difficulté qui se comprend. Tu évoques la difficulté des projets open source de passer la barrière, on va dire, du mode communautaire pour se sécuriser pour rentrer dans le monde du pentest financé. Pour les gros projets, il n’y a pas trop de difficultés, on va rentrer dans le même mode que celui d’un logiciel propriétaire où le gros projet va avoir des finances. C’est le cas du projet Dolibarr, on a des revenus grâce à différents modèles, il y a différentes sources de revenus sur le projet, ce qui nous permet de faire appel à ces programmes qui nécessitent rémunération.
Par contre, il y a effectivement une problématique pour d’autres projets, les plus petits, qui vont avoir des difficultés pour passer cette barrière financière. Là il y a plusieurs solutions, il y a eu, par exemple, la plateforme Hunter qui proposait gratuitement : la plateforme Hunter mettait en place une plateforme de bug bounty qui était financée par des dons mis en commun et qui ensuite rétribuaient à la fois la red team et la blue team. Ce modèle-là a fonctionné quelque temps, mais on voit qu’il a ses limites puisque maintenant ils ont limité ça uniquement aux projets qui sont dans le domaine de la ??? [18 min 48]. Pour les autres projets, si on n’est plus dans ce domaine-là, il y a effectivement cette difficulté et aujourd’hui c’est compliqué. Il faut avoir des équipes qui soient vraiment compétentes pour pouvoir réussir à le faire ou trouver des fonds.
Oriana Labruyère : Si je comprends bien, et par rapport à ce qu’on disait, je renvoie les auditeurs au premier épisode, par rapport à la nature même du Libre, finalement les failles de sécurité qui sont trouvées, qui sont financées notamment dans le cadre de ce programme de bug bounty vont bénéficier à l’ensemble des utilisateurs de Dolibarr, y compris les sociétés qui ont les moyens de payer, mais qui font le choix du Libre, et c’est super, mais qui, du coup bénéficient, par voie de conséquence, d’un niveau de sécurité qui, en tout cas financièrement, est assumé pas vraiment par elles.
Laurent Destailleur : C’est un autre mode. Il y a effectivement un autre mode, que je n’ai pas encore évoqué, pour sécuriser les programmes open source, qui s’applique à tous, aussi bien aux gros qu’aux petits. Souvent, ce sont les utilisateurs eux-mêmes qui font appel à des sociétés de recherche en informatique, qui elles vont aller rechercher, parce que le client utilise ce logiciel, elles ont des responsabilités, elles font appel à des sous-traitants pour trouver des failles et ces sous-traitants, dans une idée éthique, ne vont pas se contenter de remonter la faille à leurs clients, avec la correction, ils vont aussi la communiquer au projet open source. Donc, des projets open source vont bénéficier, parce que c’est un projet ouvert. C’est ce qui fait que chaque chercheur peut aller chercher les failles et les remonter au projet d’origine.
Oriana Labruyère : Du coup, c’est quand même un enjeu. L’aspect financier est quand même un véritable enjeu.
Laurent Destailleur : Quand on passe par ce biais-là, le projet open source n’a pas de contraintes financières. Par contre, il y a effectivement un système financier entre un client et la société informatique qui va faire le bug bounty. Et il y en a dans le monde aujourd’hui, beaucoup de sociétés se créent et sont spécialisées là-dedans.
Oriana Labruyère : Finalement, lors du choix du Libre sur l’aspect cybersécurité, on peut se poser cette question de savoir à quel programme est attaché le logiciel.
Laurent Destailleur : Il faut se renseigner et challenger le projet même : que faites-vous en termes de sécurité, quelle est votre équipe, quel est votre blue team, quelles démarches avez-vous ? Est-ce que vous faites appel à une société, ou pas, où est-ce que vous reposez ? Il faut effectivement se renseigner. Si c’est un point de vue important et ça doit être, aujourd’hui, un point de vue important dans tout projet informatique, numérique, il faut se poser cette question et faire ses recherches.
Oriana Labruyère : Je me disais que pendant l’épisode avec ??? [22 min 10] je n’ai pas posé cette question-là, chez Yogosha, voyez-vous une évolution de ces typologies clients et voyez-vous de plus en plus de communautés du Libre venir vers vous ? Est-ce qu’il y a eu un changement, une évolution des pratiques ?
Manon Desplat : J’avoue que je ne saurais pas répondre en pourcentage combien d’éditeurs privés on peut avoir contre les éditeurs de solutions libres, mais je pense que le maître-mot qu’on doit retenir de tout cela, c’est le complément. Il y a l’aspect communautaire qui existe, et qui est déjà très efficace, malgré son pendant ; quand je parlais du sujet de cet épisode à un de mes collègues, il m’ a dit « ce qui est bénéfique dans l'open source c’est qu’il y a un peu la politique du venez comme vous êtes ». « Venez comme vous êtes » offre l’opportunité à des personnes, à des hackers éthiques, de venir découvrir les vulnérabilités et améliorer le produit, mais aussi à des acteurs un peu plus malveillants et, forcément, peut générer ce genre de problème. D’où le fait d’avoir un programme de bug bounty en parallèle, en complément, qui peut permettent d’améliorer le produit, puisque cette fois-ci, on vérifie les typologies de profils qui actent sur ce genre de programme et on est sûr de garantir une certaine activité, puisque j’imagine qu’il y a possiblement des temps mous aussi au sein de la communauté, où il y a un petit peu moins de vulnérabilités qui sont remontées. Sur le bug bounty, on fait en sorte que les incitations monétaires, ou même l’intérêt qu’on peut porter à un programme, soient continues de sorte de pouvoir accéder à cette sécurité.
Oriana Labruyère : Un maintien de la sécurité à un niveau plutôt intéressant pour veiller à ce qu’il n’y ait pas tout de suite une faille.
Laurent Destailleur : Une campagne de bug bounty ce n’est pas une campagne, il faut que ce soit continu, parce que les failles arrivent aussi avec les évolutions et il y a aussi les évolutions technologiques
Manon Desplat : Un programme de bug bounty, ce ne s’est pas figé du tout dans le temps, c’est édité à chaque implémentation d’une nouvelle fonctionnalité, à chaque mise à jour, donc ça garantie quand même un certain intérêt pour les acteurs qui sont invités sur le programme, « il y aura peut-être des trucs à trouver ! »
Laurent Destailleur : Il faut voir que les hackers utilisent beaucoup l'open source, des outils qui sont créés aussi par des projets open source, c’est même souvent l'open source qui tire ces outils et ces outils évoluent très vite, s’améliorent très vite, donc, quelque part, les red teams deviennent de plus en plus performantes et vont jusqu’à trouver des choses que l’on ne trouvait pas il y a cinq/dix ans dans le même programme, des choses qui existaient déjà, mais qui n’ont pas forcément été trouvées, du fait de la maturité, de la complexité.
Manon Desplat : Ça rejoint totalement l’évolution dont on parlait il y a quelques minutes.
Oriana Labruyère : Finalement, si on fait un parallèle avec le logiciel propriétaire, le bug bounty fonctionnera de la même manière, ça nous permet d’arriver au même résultat, sauf que, dans un cas, on a accès à l’information par une plus grande communauté et, dans l’autre cas, on va, finalement, n’avoir que l’éditeur qui aura le résultat et qui, à date, on peut le dire, n’a pas l’obligation de remonter sa vulnérabilité, quoique dans les contrats, etc., en tout cas on attend.
Laurent Destailleur : C’est ça. On va dire que l’open source a des choses en plus par rapport au propriétaire.
Oriana Labruyère : Dans cette obligation d’information.
Laurent Destailleur : Pas une obligation légale, mais une obligation communautaire qui s’exerce. S’il y a une faille de sécurité dans un projet open source, que vous ne la corrigez pas, il y a la communauté, il y a des gens dans communauté qui vont lever les drapeaux. Il y a une pression du public qui fait qu’on est obligé d’y répondre.
Oriana Labruyère : OK. C’est pas mal la pression du public !
En préparant nos échanges, on a aussi évoqué la question des parties prenantes et de la méthodologie EBIOS. Qui a envie de répondre à cet aspect, qui est la question, en fait, de la responsabilité du tiers dans la sécurité et dans le maintien de la sécurité ?
26’ 45
Laurent Destailleur : Déjà,