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 [1], je vais me permettre de rappeler, donc Laurent Destailleurs, tu étais et tu es toujours CEO [Chief Executive Officer] et CTO [ChiefTechnical Officer] de DoliCloud [2], tu es chef de projet Dolibarr [3], 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 [4].
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, 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 c’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 ton positionnement vis-à-vis de Dolibarr ?

Laurent Destailleur : DoliCloud est une société qui propose Dolibarr en SaaS [Software as a Service], je pense que ça suffit comme information.
Dolibarr 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 [Customer Relationship Management], du VRP, de la RH, etc. C’est un logiciel qui est pas mal implanté dans les entreprises, qui est un outil critique pour les entreprises. Aujourd’hui j’assure, on va dire, la validation des é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 qu’il fallait que la sécurité informatique, puisque c’est de cela qu’on parle, la sécurité vis-à-vis du numérique, 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’information sur le secret de fabrication, etc. On s’est rendu compte que cela 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, on s’est rendu compte que le fait de documenter, de rendre public le secret de fabrication, donc le code d’un programme informatique, que, vis-à-vis des hackers, 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 ; à 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 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 ç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. Ça demande donc 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 à 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 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 aurait une réactivité 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é. Peut-on 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 dire 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 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’on 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 un programme de bug bounty sur la plateforme Yogosha. Tu me corrigeras si 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 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 [5] 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à, par le programme de bug bounty. On invite des hunters à participer parce que, chez Yogosha, nous sommes sur des programmes qui sont fermés, c’est donc 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. 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.

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 pas 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 projet 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 le système communautaire, qui marche très bien, 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écurité, 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 n’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 où 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, des deux côtés de la force.

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, 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 : Ou 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 hacker 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 slon 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, 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 à passer la barrière, on va dire, du mode communautaire pour se sécuriser et 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, 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étribuait à 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 l’IA. 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 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, qui font le choix du Libre, et c’est super, mais qui bénéficient, par voie de conséquence, d’un niveau de sécurité qui, en tout cas financièrement, n’est pas assumé 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, parce que le client utilise ce logiciel, ont des responsabilités, vont aller rechercher, 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 en 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 la 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 Yes We Hack, je n’ai pas posé cette question-là : chez Yogosha, voyez-vous une évolution de ces typologies de 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. Je pense que le maître-mot que l’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, ça 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 permettre d’améliorer le produit, puisque cette fois-ci, on vérifie les typologies de profils qui hackent 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 à pouvoir accéder à cette sécurité optimum.

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 n’est pas figé du tout dans le temps, c’est édité à chaque implémentation d’une nouvelle fonctionnalité, à chaque mise à jour, donc, ça garantit 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’avaient 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, 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 la 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 [6]. 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é ?

Laurent Destailleur : On a évoqué la cybersécurité offensive et défensive. Il y a une chose qu’il faut préciser : il faut déjà acter que la cybersécurité offensive est quelque chose d’illégal en France tant que ce n’est pas encadré contractuellement. Le métier de plateformes comme Yogosha c’est justement d’être dans un cadre contractuel pour permettre de la cybersécurité offensive.

Oriana Labruyère : Sinon c’est une sanction du code pénal, en résumé.

Laurent Destailleur : C’est quelque chose de très important. On dit toujours « je le fais, je découvre la faille, j’aide le client, je le préviens et je n’ai rien fait de mal ». Si, le fait d’essayer, c’est déjà illégal !

Oriana Labruyère : On n’a pas le droit de pénétrer le système d’information de quelqu’un qui n’a pas donné son d’accord. Le consentement en version numérique, ça marche aussi.

Laurent Destailleur : C’est une idée reçue qu’il faut tout de suite balayer. C’est donc un des intérêts de ce genre de plateforme que de pouvoir avoir ce cadre légal, en tout cas cet encadrement. J’ai perdu l’origine de la question.

Oriana Labruyère : C’était lié aux parties prenantes à EBIOS et, du coup, à l’encadrement de l’intervention de ces tiers, notamment dans l’évaluation des vulnérabilités.

Laurent Destailleur : Je ne sais pas quoi ajouter. Il faut savoir que la sécurité c’est l’affaire de tous, ce n’est pas que celle de l’éditeur. Si vous vous en remettez qu’à l’éditeur, vous ne faites pas de cybersécurité, parce que c’est un éditeur privatif. Comment avez-vous la garantie ? L’éditeur va vous dire « oui, je fais tout ce qu’il faut ». Éventuellement, vous allez pouvoir lui demander des preuves, des choses et avoir un minimum de garanties en termes de moyens.

Oriana Labruyère : Il y aura au moins un plan d’assurance sécurité.

Laurent Destailleur : Vous aurez quelque chose, mais, pour moi, ce n’est pas suffisant en termes de sécurité aujourd’hui, sauf si l’éditeur vous montre qu’il a effectivement un programme de bug bounty auquel vous pouvez avoir accès. S’il vous le montre, que vous pouvez effectivement voir et vous assurer que toute remontée est bien corrigée, vous avez quand même sécurité un peu plus forte. Mais je ne connais pas beaucoup d’éditeurs privatifs qui font ça aujourd’hui.

Oriana Labruyère : Ce qu’on pourrait dire, en tout cas par rapport à cette question, je parle sous ton contrôle, c’est aussi l’idée que finalement, en tant que partie prenante, l’éditeur doit faire sa part d’un point de vue de la sécurité, qu’il y a une vulnérabilité résiduelle à partir du moment où ne peut pas avoir accès au code, en tout cas, qu’on peut ne pas faire un audit de code, même un audit qui serait surtout fait par un tiers. Là, j’entends les clients dire « tu te rends compte, je ne veux pas donner, je refuse de donner », je les comprends, c’est le cœur du réacteur. Mais, il y a quand même cette idée que, sur la place, il y a des tiers qui font des audits de code et des audits de sécurité et dire « je fais un audit de mon code avec une périodicité y, notamment lorsqu’il y a des montées de version importantes pour veiller à ce que je ne transfère pas des vulnérabilités d’une version à une autre », c’est une manière de gérer la question par la partie prenante. Mais finalement, en l’absence de ça et même avec tous les beaux plans de sécurité, engagements de sécurité qu’on peut avoir, d’un point de vue pratico-pratique et, du coup, technique, il reste une vulnérabilité dont on ne connaîtra pas l’importance, en fait, puisque on n’aura pas pu avoir accès.

Laurent Destailleur : Aujourd’hui, la force du Libre, c’est qu’on va pouvoir se prendre un peu en main en complémentant ce que fait l’éditeur, en faisant appel à n’importe quelle société puisqu’elle a accès aux sources, donc elle va pouvoir se substituer à l’éditeur ou compléter. Par contre, sur le plan réglementaire, il n’y a pas forcément obligation.

Oriana Labruyère : Il y a quand même des obligations, il y a, aujourd’hui, des obligations, notamment en matière de protection des données, on a des obligations de sécurité, il y a régulièrement des sanctions concernant la sécurité des données. Je pense que ce que tu veux évoquer là c’est l’arrivée de la directive NIS 2 [Network and Information Security] [7] avec l’obligation de la remontée des vulnérabilités par les éditeurs ou par les fabricants, d’ailleurs, puisque ça couvre l’ensemble des acteurs sur des périmètres extrêmement larges, on pourra en reparler, mais, pour cela, il faudrait faire un épisode dédié à NIS 2, sinon on est reparti pour une heure. Il y a en effet une obligation de remontée des rapports d’alerte, des vulnérabilités et la manière de les corriger. Ce qui change beaucoup, parce que ça veut dire qu’il y a une proactivité attendue des éditeurs, à ce moment-là, ce qui est, aujourd’hui, plutôt en réaction à des choses qui sont communiquées ou à des attaques qu’ils subissaient. Du coup, finalement, c’est moins en prévention qu’en réaction.

Laurent Destailleur : Aujourd’hui, le RGPD [8], c’est surtout une obligation d’informer une fois qu’on est hacké.

Oriana Labruyère : L’obligation d’un maintien de sécurité suffisamment élevé pour garantir la sécurité de la donnée, pour le RGPD, ça va être la sécurité de la donnée personnelle, mais qui peut le plus peut moins, et je ne comprendrais pas pourquoi on ne sécurise pas de la même manière les données personnelles et les données business. En réalité, dans beaucoup de cas, les données business sont plus importantes que les données personnelles. Quand on se met à la place des directions, elles font le RGPD parce qu’il faut le faire, mais quand on leur demande où elles ont mal, elles ont mal à leurs données business, elles n’ont pas mal à leurs données personnelles, ça les embêterait et puis il y a les sanctions, etc. Mais, quand on veut pousser vraiment le projet de conformité, il faut aller sur le côté données business pour que le niveau de sécurité augmente pour tout le monde, pour tout le périmètre de l’entreprise.
Sur la question qui nous occupe, qui est liée au Libre, finalement on est sur la même situation qui est de dire que les communautés, de ce que je comprends, de ce que vous dites, vont être beaucoup plus proactives et, par des programmes comme propose Yogosha, on va avoir une proactivité très forte et une transparence qui, du coup, est là pour renforcer la confiance. Alors que dans le propriétaire, aujourd’hui, parce qu’on n’a pas encore cette obligation de remonter la vulnérabilité, on a l’obligation de la corriger, comme on ne peut pas louer un habitat qui serait insalubre, on n’a pas le droit de laisser un trou dans la raquette alors qu’on le sait et on n’a pas droit de commercialiser, sinon on aurait une non-conformité légale à la livraison du produit, puisque l’obligation de sécurité fait partie de la conformité du produit lorsque je le mets à disposition. Le logiciel propriétaire doit donc respecter la conformité d’un point de vue légal. Là, en fait, c’est plutôt l’obligation de la transparence qui est liée à la nature de la vulnérabilité et les mesures, la manière dont on va corriger, ce qui, pour moi, est un changement, en tout cas une évolution pour les éditeurs, à venir, le 7 octobre 2024.

Laurent Destailleur : Tu as cité NIS, on peut citer aussi le Cyber Resilience Act [9] il y en a plein.

Oriana Labruyère : Bien sûr. On peut citer aussi le règlement IA [10]. C’est le sens du vent aujourd’hui.

Laurent Destailleur : Dans la finance, on peut citer DORA [Digital Operational Resilience Act]. Plein de choses arrivent qui font que, effectivement, on va avoir de plus en plus d’obligations et ce n’est pas plus mal parce que aujourd’hui, il faut le reconnaître, les projets informatiques sont des passoires.

Oriana Labruyère : Si on veut beaucoup schématiser, on pourrait dire qu’aujourd’hui on a des objectifs, on a des obligations qui sont finalement relativement larges et qu’il y a une obligation de sécurité. Par contre, on peut tout à fait dire que, là, on nous met en face des obligations d’un point de vue méthodologique pour démontrer d’avoir réalisé cet objectif de sécurité. En fait, on passe sur un système de compliance, qui est plutôt un système anglo-saxon de la démonstration de la conformité, de se rendre, même pas responsable, le côté accountability, c’est vraiment cette idée qu’on va démontrer, donc il y a la proactivité de la démonstration. C’est finalement ce que vous faites, Yogosha, dans le programme DoliCloud, vous n’avez pas attendu NIS 2 ou le Cyber Resilience Act.

Manon Desplat : Tu as répété plusieurs fois un mot dans ton propos, c’est la notion de confiance, Laurent, peut-être as-tu un autre avis. En open source, on fait déjà confiance : on ouvre le code, il y a une communauté qui y a accès, etc. Chez Yogosha, on fait énormément de pédagogie pour que la sécurité offensive ne soit plus le cliché des méchants hackers qui vont hacker sur un programme. Cette notion de confiance est dure à mettre en place et ce genre de réglementations, que tu as citées, vont permettre aussi à obliger certains éditeurs à faire plus confiance, parce que la sécurité offensive devient nécessaire. J’ai l’impression que cette notion de confiance est déjà actée pour des produits qui sont en open source, donc c’est plus aisé de se tourner vers la sécurité offensive comme peuvent l’être des opérations de bug bounty ; je sais pas.

Laurent Destailleur : Pour moi, c’est nécessaire, c’est plus facile parce que le code est ouvert, qu’il n’y a pas de démarches administratives à mettre en œuvre.

Oriana Labruyère : Finalement, tu dis que c’est presque culturel en fait. La transparence est culturelle dans le Libre.

Laurent Destailleur : Ça fait partie de l’ADN d’un projet open source.

Oriana Labruyère : Alors que dans le propriétaire, finalement, on protège ce qui est précieux.

Laurent Destailleur : On ne veut pas que ça se sache, on ne veut pas qu’une faille de sécurité soit connue, parce qu’on se dit que si elle est connue… Alors que la mentalité de l’open source c’est l’inverse. On veut que ce soit transparent.

Oriana Labruyère : Ça peut être contre-intuitif de se dire que l’information de la faille rend, en réalité, plus fort. On a contre-intuitivement cette idée que l’information de la faille va affaiblir l’image de l’éditeur. C’est vraiment un combat, je milite pour un #MeToo de la faille informatique et de la cyberattaque, j’ai l’impression que c’est vraiment un sport quotidien. À partir du moment où ça devient un sport quotidien, au contraire, soyons dans la bonne équipe, plutôt l’équipe défensive, en réaction et en prévention, avec des acteurs comme Yogosha. Justement, se positionner et dire « je suis un acteur responsable, donc je prends les devants – comme vous le faites – et j’informe pour que toi aussi tu te renforces en ayant l’information de cette petite zone de faiblesse sur laquelle on est en train de travailler ». C’est mon intuition, mais j’ai l’impression que c’est très contre-intuitif.

Laurent Destailleur : C’est contre-intuitif, le mot est là et, pendant longtemps, cet aspect contre-intuitif était en faveur du fermé. Aujourd’hui l’histoire montre, avec les expériences, les acquis, les compétences qui évoluent, qu’il vaut mieux avoir un modèle ouvert, pour être sécurisé, qu’un modèle fermé.

Oriana Labruyère : C’est bien résumé, n’est-ce pas !

Laurent Destailleur : Aujourd’hui, plus beaucoup de personnes pensent le contraire, en tout cas dans le monde informatique. C’est clair qu’auprès des utilisateurs il y a encore ce côté contre-intuitif. Mais au niveau des équipes informatiques, on va dire expérimentées, c’est en train de disparaître.

Oriana Labruyère : Pour moi, là l’enjeu est vraiment lié à la pédagogie, notamment au niveau des directions, peut-être que c’est un peu ce que nous sommes en train de faire dans ce podcast. En réalité, quand on se met à ouvrir les codes, elles ont quand même l’impression qu’il y a des choses qui vont leur échapper, ce que je comprends, du coup, j’ai l’impression que c’est vraiment lié à la pédagogie.

Manon Desplat : Je pense que les mots clés sont pédagogie et collaboration, les petites lumières avec la blue team et la red team, donc red team côté offensif et blue team qui va s’occuper de la défense des systèmes d’information. La pédagogie sert à cette collaboration. Comme on le disait plus tôt, quand le hunter, le hacker, va remonter une faille, il veut faire en sorte que vous puissiez la reproduire de votre côté pour pouvoir la corriger. C’est donc vraiment une collaboration des deux équipes qui permet d’avoir un réel impact sur la sécurisation des systèmes d’information, sans cela, il n’y a rien.

Laurent Destailleur : Blue team et red team sont aujourd’hui tellement complémentaires qu’on en est à utiliser un autre terme, purple team, les équipes violettes qui permettent, justement, de faire en sorte qu’il y ait une jonction entre les deux : une blue team toute seule ne sert pas grand-chose, la red team toute seule ne sert pas à grand-chose. Si on veut vraiment sécuriser, il faut que les deux équipes travaillent sur le projet.

Oriana Labruyère : Je pense que c’est bien, ça veut dire que sans collaboration, il n’y a rien.

Manon Desplat : Je pense que c’est une bonne conclusion.

Oriana Labruyère : Du coup, on va arriver à la conclusion. Merci pour cette transition.
Manon, est-ce que tu veux rajouter quelque chose sur la fin de ce podcast ? Est-ce que tu penses à une idée forte qu’il ne faut pas oublier en se quittant ?

Manon Desplat : Je reviendrai sur les deux mots que tu as évoqués, pédagogie et collaboration, j’en avais un autre, mais je l’ai oublié.

Oriana Labruyère : Confiance.

Manon Desplat : Confiance, ce n’est pas mal. Donc ces trois maîtres-mots et je te laisse faire la conclusion que tu feras mieux que moi.

Laurent Destailleur : Je reviendrai sur le mot contre-intuitif. Ne pensez pas que vous êtes sécurisé parce que vous êtes fermé, vous avez tout faux, ça n’arrête pas un hacker, par contre ça arrête tous les autres, tous ceux qui veulent vous aider à être plus sécurisé, eux, ça va les freiner, ça ne va pas freiner le hacker. Prenez un modèle ouvert si vous voulez être sécurisé, vous n’avez plus le choix aujourd’hui.

Oriana Labruyère : Merci beaucoup pour ces conclusions, c’est votre conclusion.
Merci, chers auditeurs et auditrices, de nous avoir suivis sur cet épisode de La Robe Numérique. Vous pouvez retrouver la vidéo sur nos comptes YouTube et Instagram et puis, évidemment, la version 100 % audio sur l’ensemble des plateformes de podcast, celle que vous préférez. N’hésitez pas à nous mettre cinq étoiles, parce que ce n’est pas mal pour notre propre remontée de l’information, pour que nous puissions faire de la pédagogie toujours au plus grand nombre. N’hésitez pas à partager ce podcast et, évidemment, à nous écrire si vous avez des questions, des remarques, ou bien, si vous avez envie d’entendre parler de sujets particuliers. N’hésitez pas à nous contacter sur l’ensemble des plateformes.
Merci encore et à très vite sur le podcast de La Robe Numérique.