Open source vs. cybersécurité - La Robe Numérique
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,
