Post Mortem · Épisode 04
#4 — La divulgation de vulnérabilités, théorie et pratique.
Écouter cet épisode
Épisode 4 · La divulgation de vulnérabilités, théorie et pratique
Spotify
Apple PodcastsSommaire
Avec Rayna Stamboliyska, VP Governance & Public Affairs @ Yes We Hack
Transcription
François: Bonjour à toutes et à tous et bienvenue dans Post mortem. Dans cet épisode, nous allons discuter de cyber sécurité et plus particulièrement de divulgation de vulnérabilités. Alors, on va se placer dans un contexte qui est le suivant, c’est à dire en tant qu’utilisateur d’un service en ligne, d’une application. Je remarque qu’il y a une faille, une vulnérabilité, quelque chose qui serait possible d’exploiter afin d’avoir des accès privilégiés au système d’information ou bien de compromettre des données des utilisateurs. Comment puis-je faire, en tant qu’utilisateur bien intentionné, pour remonter cette faille, cette potentielle menace, aux éditeurs de logiciels afin qu’ils patchent la vulnérabilité pour assurer la confiance des utilisateurs dans le service. On va voir que cette dimension confiance de l’utilisateur est vraiment fondamental au sein de ce process de divulgation de vulnérabilités. Pour échanger sur la divulgation de vulnérabilités, j’ai la chance d’accueillir Rayna Stamboliyska, Bonjour Rayna. Alors avant de zoomer sur la divulgation de vulnérabilités. Est-ce que tu pourrais Rayna nous présenter brièvement ce que tu fais à Yes We Hack et ensuite venir contextualiser, finalement, les différents outils à disposition d’une entreprise pour assurer sa cyber sécurité ? Et quelle est la place de la divulgation de vulnérabilités dans cette boîte à outils ?
Rayna: Actuellement, je suis la VP Gouvernance et Affaires Publiques de Yes We Hack. Donc pour les personnes qui ne connaissent pas Yes We hack. C’est une société française, comme on dit, une PME innovante, qui fait principalement du bug bounty, donc du contrôle continu de la sécurité où l’approche diffère des audits habituels. Dans le cas d’un bug Bounty, ce qu’on fait c’est, moi client, je fais appel à une plateforme, tel que Yes We Hack, et je demande à ce que la plateforme mobilise sa communauté de chasseurs de vulnérabilités pour auditer mes périmètres. Je défini le périmètre technique et voilà. L’approche intéressante là-dedans, en plus de l’aspect crowd sourcing, finalement du contrôle de sécurité. C’est aussi l’engagement de résultat, c’est à dire que, contrairement à l’usuel engagement de moyens, dans les pens tests d’habitude, dans le cas d’un bug Bounty, les chasseurs de bugs vont identifier idéalement les problèmes de sécurité, vont les remonter par le biais de la plateforme au client. Et si la vulnérabilité est validée, vont recevoir enfaite une prime, le Bounty. Qui est défini d’après une grille spécifique à chaque programme qui dépend de la sévérité du bug identifié.
Rayna: C’est dans cette optique, dans ce modèle économique assez différent de ce qu’on connaît habituellement, de paiements à la faille. C’est pour ça qu’on dit qu’il y a un engagement de résultat dans cette approche-là plutôt qu’un engagement de moyens. Ce qui est intéressant avec le Bug Bounty, c’est l’aspect contrôle continu. Quand tu mets une application en bug bounty, le programme peut ne pas avoir de date de fin. L’examen, l’Inspection, si on veut, elle se fait finalement en permanence, ce qui fait que l’approche agile se marie, très bien avec cette approche d’inspection de sécurité. Parce que en même temps qu’on fait les développements, son sprint, en fait, on peut pousser des choses sur la pré-prod, etc. Avoir des chasseurs de bugs qui regardent et en fait corriger avant même que le produit ou le service soit mis en prod. Et donc, en fait, réduire à chaque sprint, la quantité de vulnérabilités qui existent en production. Même si c’est une approche intéressante, etc. À l’impossible, nul n’est tenu. On aura toujours des vulnérabilités dans les produits et services en production. Faut se rendre à cette évidence-là. Et c’est là où, justement, une approche telle que la divulgation coordonnée de vulnérabilité est intéressante. C’est l’autre sujet dont je m’occupe et pour lequel Yes We Hack est fer de lance en France, mais aussi en Europe, de plus en plus au niveau global également. Qui est en fait d’accepter que, oui, des vulnérabilités existent et existeront toujours. Pour plein de raisons. Et que de plus en plus de gens sont en fait en capacité d’identifier justement des comportements techniques anormaux, bizarres, des vulnérabilités plus ou moins spécifiques, etc. Ces gens-là, enfaite, n’ont pas de lien contractuel d’audit, avec l’éditeur. La question qui se pose dans ces cas-là, c’est Mais qu’est-ce que j’en fais ? Parce que lorsqu’on a vu des gens râler sur les réseaux sociaux, que ce soit tweeter, reddit ou autre que “machin a tel vulnérabilité, je leur ai dit et ils ne répondent pas. Alors je vais m’épancher sur les réseaux sociaux, espérant les faire bouger un peu. En fait, il y a toujours cette tension de savoir si je suis externe à l’entreprise ou à l’administration, et que je veux leur signaler un truc, et bien ils ne me connaissent ni d’Ève ni d’Adam, je n’ai pas de contrat d’audit avec eux. Donc enfaite la situation est super bizarre. Mais justement, l’approche permet qui d’encadrer ces interactions là ; On appelle ça la divulgation coordonnée de vulnérabilités. Il y a deux standards internationaux ISO qui existent pour justement structurer cette activité-là. Qui peut être assimilé à une visibilité passive, par opposition enfaite à l’approche de chasse de bug active du bug bounty. La divulgation via une politique de divulgation c’est plutôt une visibilité passive. Je dis que je suis à l’écoute, que je suis bienveillante envers les tiers qui souhaitent me remonter des problèmes, mais je ne les invite pas pour autant à le faire de façon active, c’est à dire à vraiment aller inspecter, à scanner, à brute forcer, etc.
François: Là, tu viens de soulever quelque chose de très important pour le service Provider, qui est: l’importance de mettre en place des règles d’engagement claires sur les moyens qui peuvent ou ne peuvent pas être employés pour découvrir des vulnérabilités et ensuite sur la façon dont cette vulnérabilité peut être communiquée au service provider par un chercheur qui vient de la trouver. D’ailleurs, à ce sujet, il existe, comme tu as dit, deux normes ISO qui vont venir définir un petit peu. D’une part, ce qu’est la divulgation de vulnérabilités. Donc, pour ça, je vous réfère à la norme ISO 29 147 et une autre norme ISO, la norme 30 111. Elle, vient définir le processus à suivre pour la gestion de ces vulnérabilités une fois qu’elles ont été remontées. Pour résumer, on a évoqué des systèmes actifs de protection pour préserver l’intégrité d’un système d’information, réaliser des audits de sécurité régulièrement, avoir un programme de bug bounty. On est vraiment sur des approches actives. Et en parallèle, il y a cette approche complémentaire qui est, s’équiper d’un processus de divulgation coordonnée et l’expliciter vis à vis de ses utilisateurs, c’est à dire le mettre clairement à disposition sur une page Web de notre service pour qu’il soit facilement trouvable et que le plus grand nombre puisse y accéder, les comprendre si jamais ils ou elles ont besoin de remonter une vulnérabilité.
François: Donc, si cet épisode porte sur la divulgation coordonnée de vulnérabilités, je pense qu’il est important tout de même de garder en tête les trois options qui se présentent à un utilisateur qui vient de découvrir une vulnérabilité. Puisque finalement, cette personne peut choisir de soi : garder cette vulnérabilité pour elle. Dans ce cas-là, c’est ce qu’on appelle de la Non Disclosure, peut être dans l’espoir d’en tirer un avantage financier, de la monétiser. Une autre option est de faire de la Full Disclosure. Divulgation totale. Où là, on va en parler sur les réseaux sociaux, sur un blog, dans des mailing lists. L’objectif est vraiment de porter cette vulnérabilité dans tous ses détails au grand jour. Et donc la troisième, la divulgation coordonnée dans laquelle l’utilisateur va suivre les règles d’engagement proposées par le Service Provider. Donc là, on a vu qu’il y a deux approches pour la divulgation. Soit elle est totale ou elle est coordonnée / responsable et en fait ces deux approches différentes vraiment dans la façon dont elles envisagent l’utilisateur final et ses capacités à réagir face à une vulnérabilité. Pour la divulgation totale, on considère que l’utilisateur final est un expert de son système d’information. Il est fondamental qu’il soit averti au plus tôt pour pouvoir évaluer les risques. Prendre des contre-mesures si nécessaire pour limiter son exposition au risque. Le corollaire, évidemment, c’est en mettant une vulnérabilité au grand jour. On risque potentiellement d’augmenter le nombre d’attaques puisqu’elle est facilement accessible en ligne. Et on peut la répliquer. Donc des acteurs qui n’auraient peut-être pas les compétences techniques pour reproduire cette attaque. Le peuvent maintenant puisqu’elle est disponible en ligne. C’est pour ça que dans le cadre de la divulgation coordonnée. On a une approche différente en se disant, mettre la vulnérabilité au grand jour ne va vraiment pas aider la plupart des utilisateurs à y faire face et c’est pour cela qu’il vaut mieux prévenir l’éditeur. Pour la personne qui découvre cette vulnérabilité, prévenir l’éditeur de services. Se coordonner sur le processus à suivre pour réparer ces vulnérabilités, pour patcher, proposer un correctif et une fois que c’est fait, peut être communiquer sur : Il y a eu une vulnérabilité; On l’a fixé. Déployez ce patch, c’est important. Et voilà. D’ailleurs, est ce que tu peux nous parler un peu de comment se passe la remontée de vulnérabilités en pratique ?
Rayna: Le plus souvent, ce qui va se passer c’est que tu vas signaler une vulnérabilité, dans le meilleur des cas, ça va arriver à destination, c’est à dire, par exemple chez l’équipe sécurité. C’est là où tu croises les doigts, tu serres les fesses, pour que, derrière, l’équipe sécurité ait des interactions construites avec les responsables des actifs pour qu’une correction soit déployée le plus vite possible. Il ne suffit pas que l’équipe sécurité soit au courant. L’équipe sécurité a plus généralement un rôle de contrôle. Elle ne peut pas être juge et partie ; et contrôler et développer. Donc, en fait, tu vas te retrouver dans la situation où des processus internes, là c’est des interactions entre différents départements ou que sais-je. Qui enfaite vont se mettre en branle, ou pas, pour venir à bout, d’un potentiel risque de sécurité, pour l’organisation qu’elle soit entreprise, ou administration publique, mais aussi pour ses partenaires, revendeurs, intégrateurs, etc. Et pour les utilisateurs finaux. Tout ce beau monde. S’il n’y a pas eu déjà une réflexion au sein de la boite en question, pour se dire mais comment effectivement, est-ce que des gens nous remontent des choses comme ça, on ne les connait pas, ils ne sont pas sous contrat pour faire des audits chez nous, etc. Si des gens ne se sont pas posé ces questions-là, tu peux être certain que ça risque de pas très bien avancé une fois qu’un tel signalement est reçu. C’est pour ça qu’on promeut aussi la divulgation coordonnée comme une approche de l’éventail de sécurité. Ce n’est pas un substitut aux pen tests, au bug bounty, etc. C’est un truc de visibilité passive, en plus de toutes les mesures qu’on prend par ailleurs. C’est intéressant de voir l’apport de ce genre d’approche. Par exemple, on a un site qui parcourt toute sorte de politiques de ce genre-là. Cela s’appelle firebounty.com, j’avais commencé à observer, les différentes politiques de divulgation que des organisations mettent en place. J’en ai fiché 6 qui ont des pages de remerciements publiques très bien nourries.
Rayna: Parce que t’as plein de gens qui peuvent avoir ce genre de politique de divulgation, mais pas tout le monde ne fait des remerciements publics. Beaucoup de gens le font en disent, “voilà machin m’a remonté tel problème à telle date, voilà son compte Twitter, GitHub, LinkedIn, etc.
François: Et qu’est-ce que ça change d’avoir ses remerciements sur une page publique?
Rayna: Alors pour la personne qui remonte, ça s’appelle du capital social. Ça fait vachement plaisir de voir qu’il y a une bienveillance et une appréciation de cette bonne foi qui. Ca c’est un truc qui est super difficile à faire comprendre aux gens. Que : quand moi, avec mon vrai nom, je viens te voir, t’expliquer que t’as un problème dans ton service, dans ton produit, je ne suis pas suicidaire. Je ne veux pas que tu viennes me chercher des noises au tribunal. Je veux vraiment t’expliquer que t’as un problème, pour que tu le corriges. Mais il y a plein de gens qui sont en mode “Heu ! Piratage ! Bouh!”. Parce qu’on entend beaucoup parler des méchants hackers, pirates, etc. Qui en veulent à ton compte PayPal ou PornHub ou ce que tu veux. Mais justement, on entend très peu parler de la bonne majorité des gens. Qui en fait, je pense que dans les auditeurs et auditrices, il y en a plein qui ne supportent pas les trucs mal fait. Et donc quand ils voient un truc mal fait, ça les démange, ça nous démange de dire “Mais mince alors, on peut mieux faire, allez-y, je vous explique comment, allez corriger, ce n’est pas très compliqué.” Et cette démarche-là elle est naturelle. Puisqu’on est tous l’utilisateur final de quelqu’un. Et c’est cette démarche-là qui est d’une complexité saint-nom. Parce qu’aujourd’hui, une telle démarche peut très bien être qualifiée pénalement, même s’il y a une bonne intention derrière.
François: On parle de la démarche de signaler.
Rayna: Tout à fait. “Mais oui, mais comment tu as vu, comment tu as fait pour la trouver ?”
François: En France, l’article 323 1 du Code pénal dispose que l’intrusion et le maintien illégitime dans un système d’information sont punis (par amende et emprisonnement.) Le cadre réglementaire a évolué avec l’adoption de l’article 47 de la Loi pour une République numérique du 7 octobre 2016. Il inscrit la possibilité de rapporter une vulnérabilité à l’Agence nationale de la sécurité systèmes d’information, l’ANSSI, sans craindre de poursuites de la part du procureur de la République, à condition pour le divulgateur d’être de “bonne foi”. La rédaction de ces articles sous-entend que le chercheur en sécurité ne doit ni contacter le responsable du système d’information concerné, ni divulguer la vulnérabilité à qui que ce soit d’autre que l’ANSSI. En outre, l’article 47 ne protège que des poursuites engagées par le procureur de la République sur dénonciation d’un agent public, mais pas de celle engagées par le responsable du système concerné. Ce dernier peut donc engager des poursuites à l’encontre d’un hacker bien intentionné. Ceci est un extrait du Livre blanc de Yes We Hack sur la divulgation coordonnée de vulnérabilités.
Rayna: Donc, quand on reste sur le territoire national, c’est “simple”, on peut être d’accord ou pas avec la décision du juge. Il y a des recours ou autres. Mais dès qu’on commence à se placer dans un contexte transfrontalier, il ne faut pas oublier, sur Internet, il y a beaucoup de choses qui n’ont pas de frontières. L’usage existe aussi de, moi en France, dans mon utilisation d’un service américain, allemand ou patagonais, trouver une vulnérabilité et vouloir la signaler au gestionnaire ou éditeur du service. En fait, ça peut très bien constituer chez eux ce qu’on appelle du piratage et donc on arrive à cette situation transfrontalière qui tout de suite met le boxon dans ces considérations-là. En plus de toutes les difficultés, de timing, d’interaction avec les tiers. Est-ce que j’en parle finalement aux utilisateurs finaux quand c’est réglé ou pas ? Comment je leur en parle ? Est-ce que je leur parle si c’est grave ? Ou est-ce que je leur en parle avant pour les informer qu’il y a un risque potentiel et que je suis dessus ? Il n’y a pas une réponse unique à ces questions. Ces contextes-là sont tous très différents. Du coup, la réponse législative n’est pas nécessairement la réponse la plus optimale. C’est à dire que ce serait bien qu’il y ait une clarté sur le sujet au niveau légal, en tout cas, dans des cadres spécifiques pour commencer. Mais il y a aussi quelque chose qui s’appelle la responsabilité des entreprises ou des administrations publiques, à partir du moment où tu mets à disposition un service ou un produit numérique, tu as la responsabilité d’assurer le meilleur niveau possible de qualité et de sécurité de ce que tu mets à disposition. C’est là où justement, implémenter une politique de divulgation coordonnée de vulnérabilité, fait que justement, les entreprises, les administrations publiques, etc prennent justement cette responsabilité là en charge et donc permettent, sans que la loi vienne leur faire petit coup sec derrière la nuque, permettent une amélioration globale de la sécurité, y compris par ce biais-là de tiers qui leur signalent des choses. Ce qui est intéressant, c’est que moi, je fais aujourd’hui chez Yes We Hack ce que je fais, parce que justement, je me suis cassé les dents pendant je ne sais pas combien de temps à tenter finalement de remonter des problèmes. Certes, côté sextoys, mais pas seulement à des fabricants. Qui, en fait, c’est très, très rare.
François: Soit ne répondait pas? Soit ne savait pas quoi faire ?
Rayna: Voilà. C’était très rare qu’il y ait une vraie réception pour dire “merci beaucoup, on va regarder ça, etc”
François: Il y a déjà une grosse valeur d’encouragement. Rien que dans ces messages de prise de conscience de la part des éditeurs, soit de ces produits IoT, de ces solutions. Donc, effectivement, cette première étape qui est la prise de conscience par l’éditeur, que ce soit d’un objet IoT, d’un objet connecté ou d’un éditeur de logiciels. La première étape dans ce processus de divulgation coordonnée de vulnérabilités, c’est “l’acknowledgment”, la prise de conscience de la part de cette entreprise de la vulnérabilité et de dire “OK, ça on l’a pris en compte. Peut-être que la résolution de cet incident ne va pas venir demain, qu’il faut différencier le temps entre lequel on porte connaissance de l’incident et ensuite la moulinette interne de priorisation des tâches, transmission aux équipes de développement et mise en place du patch.” Effectivement, ça ne se fait pas en un claquement de doigts. Il faut développer ce correctif, le déployer. En tout cas, ce que tu as mentionné, c’est que cette première étape de prise de conscience est fondamentale pour les entreprises afin d’encourager la remontée de vulnérabilités.
François: Est-ce que tu aurais d’autres bonnes pratiques ou des roles models, des entreprises qui sont à la pointe dans ce domaine-là, à partir desquelles s’inspirer pour implémenter une politique de divulgation?
Rayna: Alors il y a bien sûr différentes choses à faire. Il y a un vrai apport de cette approche de visibilité passive. Ce que j’ai vu justement en regardant quelques pages de Hall of Fame, de remerciements, de grosses boites. J’ai dû en regarder 6 boîtes comme ça. Et typiquement, pour Nokia, c’est très intéressant parce qu’ils mettent des remerciements à toutes les personnes qui le souhaitent qui leurs ont remonté des vulnérabilités via leur politique de divulgation. Donc qui souhaitent être nommés. Ils ont ça depuis plusieurs années et en fait, il s’approche des 500 vulnérabilités remontées uniquement par ce biais-là, et ça, d’après les critères définis. Tu en as certainement plus qui ont été remontée. Certain ont potentiellement pas été retenu parce que ça a été sur des produits ou des services qui ne sont plus en circulation. Ou du legacy qui traine quelque part mais sur lequel il n’y a plus de support, ou les gens n’ont pas voulu être nommé publiquement comme ayant remonté la vulnérabilité.
François: Donc, à ce sujet-là, ça parait hyper important de venir définir le périmètre sur lequel remonter les Vulnérabilités.
Rayna: C’est ça. Et donc, cela m’emmène justement à cette histoire de règles, de règles d’engagement. Et en fait la bonne pratique, c’est justement, de préciser quelles sont les règles d’engagement. Pourquoi ? Parce que quand j’affiche, moi, Nokia ou moi boite Tartempion. Quand j’affiche que j’accepte les remontées de vulnérabilité par des tiers, et que, si ces tiers-là respectent les règles du jeu. Je ne vais pas aller leur chercher des noises au tribunal. Cette politique elle a une valeur. C’est un engagement. Elle a une valeur légale, au sens où c’est un engagement entre nous, que, tu ne fais pas de DDOS, attaques par déni de service, tu ne fais pas de Brute force, si tu me remontes quelque chose en respectant les règles ; Je te serais reconnaissant et je n’aurais pas de raison d’aller te trainer au tribunal. Typiquement, tu as des gens comme F-Secure, qui est un pure player, éditeur de logiciels, mais beaucoup plus de choses que ça, finlandais. Par exemple, sur leur politique de divulgation à un paragraphe dédié où en fait ils te disent “Nos juristes nous ont demandés de préciser ça”. Et donc ils t’expliquent, par exemple que, si tu leur remonte des vulnérabilités parce que tu reversé, donc tu as fait de l’ingénierie inverse sur leur solution. En fait, c’est acceptable parce que d’après la législation européenne, l’ingénierie inverse est proscrite en général, sauf quand il s’agit de situations d’interopérabilité. Typiquement, le fait que LibreOffice puisse tenir du .docx, qui est un format propriétaire Microsoft Word. Ça, c’est de l’interopérabilité. En dehors de ça, on n’aime pas trop le reverse engineering, légalement parlant. Là ce que te dit F-Secure, c’est qu’en plus de toutes les règles d’engagement, pas de DDOS, pas de brute force. Ils te disent aussi que, si vous avez reversé un de nos produits et que vous avez trouvé des choses que vous voulez nous remonter. On est d’accord, on ne va pas venir après vous, parce que vous avez enfaite, enfreint la loi en reversant. Mais parce que, ici se sont nos produits. A partir du moment où l’entreprise, ou l’administration publique, ce sont ses produits ou services, en fait, si elle, elle décide de ne pas utiliser la loi pour venir après toi c’est tout. Quand elle explique noir sur blanc littéralement, qu’elle ne fera pas, qu’à cette condition-là, tu peux y aller. Cette règle d’engagement, tu peux y aller. C’est un signe très positif, justement, envers les gens. C’est là où ça ajoute énormément de valeur à l’organisation. La preuve, on est en train d’en parler là. Je suis que je suis face à des gens qui comprenne l’apport que j’ai d’aller tweaker par ci, par-là, etc. Pour m’assurer que le produit ou le service qui est mis à disposition, n’a pas de gros problèmes de sécurité et qu’en plus, s’il en a, l’éditeur est suffisamment bienveillant pour me dire “merci beaucoup. On va investiguer ça” Tu as même des gens qui vont s’engager publiquement dans leur politique de divulgation sur des SLAs, des Service Level Agreement. Dans le cadre d’un fournisseur de cloud, il va te dire que, mes SLA c’est « le service est disponible, 99,99999% du temps ». Donc tu as ce genre d’engagement au niveau de la communication. Tu as pas mal d’organisations qui vont dans leur politique de divulgation, en plus de te dire “voilà ce qu’on accepte et ce qu’on n’accepte pas, notre focus c’est notre appli mobile, donc le périmètre c’est l’appli mobile” Dans ces politiques-là, tu as aussi un engagement de temps de réponse et de temps de correction. Et c’est là où tu vas avoir des gens qui vont te dire, par exemple, “On s’engage à vous répondre dans les 48h ou 72h après le signalement. Si on ne vous a pas répondu dans les 72 heures, n’hésitez pas à nous solliciter comme ça. Et on s’engage à faire l’investigation, la correction et le déploiement du patch dans un délai de 30 jours, dans un délai de 90 jours, etc.” Moi je ne connais pas telle boite ou telle boîte, mais qu’est-ce que ça me dit quand je lis ces politiques-là? En fait, ce que je comprends, c’est que les gars, ils ont quand même fait du chemin intellectuellement, mais aussi du point de vue organisationnel, du point de vue interaction à long terme. Ils ont vraiment fait du chemin pour afficher un tel engagement comme ça. Et en fait, si le choix se pose à choisir tel service ou tel autre. Je fais partie des gens bizarres qui lisent les politiques de confidentialité jusqu’à la fin. Mais je fais aussi partie des gens qui regardent ce genre d’engagement. Et ce que tu vois aussi, c’est que c’est le genre de choses, La politique de divulgation qui risque de se retrouver une obligation légale parce que, pour nos auditeurs et auditrices, je signale un petit règlement européen. Qu’on appelle de son petit nom, le CyberAct, un règlement d’application directe, contrairement à une directive qui doit être transposée etc.
François: Le 12 mars 2019, les députés européens adoptent le Cyber Security Act.
François: En résumé, ce règlement, d’une part, vient renforcer l’ENISA, l’Agence européenne de la cyber sécurité, en lui accordant un mandat permanent, en renforçant ses ressources financières et humaines.
François: D’autre part, ce règlement établit le premier cadre de certification de cyber sécurité à l’échelle de l’UE, afin de garantir une approche commune de certification de cyber sécurité dans le marché intérieur européen et, à terme, d’améliorer la cyber sécurité dans une large gamme de produits et de services numériques.
Rayna: Donc le CyberAct s’applique déjà. Dans le CyberAct, tu as beaucoup de choses, mais une d’elle, est l’obligation pour l’Agence européenne de cyber sécurité, l’ENISA, de créer des schémas harmonisés de certification. Harmonisées au sein de l’Europe. Qui pourraient justement constituer un indicateur très clair pour les consommateurs, mais pas seulement pour les partenaires aussi, etc. des engagements de sécurité des différents fabricants, éditeurs, opérateurs de services et de produits numériques. On attend le premier schéma européen pour le cloud en mars 2021. Dans le cadre de ces schémas-là, tu as une exigence qui est que, toute entité qui édite un produit ou un service numérique, doit montrer, ne serait-ce que l’ébauche d’une politique de divulgation, parce que ça participe justement à son engagement global pour une meilleure sécurité. Et donc, en fait, on arrive d’un truc qui finalement, pour moi comme pour beaucoup de gens, ça a commencé comme un problème de gens, de techos quoi. J’ai vu un truc qui est mal fait, qui a des répercussions négatives potentielles, même très importantes parfois. Et j’en arrive à ce que l’interaction et la prise en compte de ces remontées-là, soit incluse dans des textes de loi et des exigences en direction de tout le monde. Avec les ramifications que ça pour la confiance des utilisateurs, et des partenaires, et en fait, en dehors de choses très imagés comme ça, aussi pour la sécurité réelle, concrète des produits services.
Rayna: Donc, idéalement, les gens auraient une démarche de DevSecOps, là je suis en train de te dropper du buzzword. Désolé, mais pour moi, c’est pas du tout du buzzword, c’est une culture de responsabilité, de création et de maintien de services, de qualité et de bon niveau de sécurité moderne parce que de la même manière que je renouvelle enfaite mon service, mon produit, etc. fréquemment. La sécurité, doit suivre, ce n’est pas un truc part. Ce n’est pas un plugin, ce n’est pas une option, ce n’est pas un Add-On. Parce que responsabilité, parce que l’inter connectivité et interdépendance. Et donc, si on veut bien faire, on fait une approche de contrôle continu de la sécurité, pro active, typiquement avec le Bug Bounty.
Rayna: Là, je prêche pour ma paroisse et on fait aussi une approche de visibilité passive pour compléter les écueils existants par ailleurs, cette visibilité passive, on appelle ça une politique de divulgation de vulnérabilités.
François: Ok donc si on fait un petit bilan des thèmes abordés.
François: On a vu que effectivement la divulgation coordonnée de vulnérabilité, c’est une approche passive, qui arrive en complément d’approches actives telles que réaliser des audits, avoir un programme de Bug Bounty. Et plus particulièrement pour la divulgation coordonnée, on a identifié quelques éléments.
1. Alors il y a la question du périmètre, c’est à dire, de définir clairement sur quelle partie notre produit ou service on est intéressé pour que des vulnérabilités nous soit remontées.
2. Il y a aussi le point sur les SLAs, Service Level Agreement et plus particulièrement est ce qu’on peut s’engager sur des délais ? D’une part, sur le temps que l’on va mettre pour répondre à un utilisateur, un chercheur, une fois qu’il nous a remonté une vulnérabilité et ensuite sur le temps qu’il nous faudra pour déployer un patch. On a vu que c’est quelque chose qui va vraiment augmenter la confiance des utilisateurs, si on s’engage fermement à livrer un patch dans tant de jours.
3. Enfin, on a aussi parlé des règles d’engagement, idéalement on a des règles d’engagement claires sur ce qui est permis ou non pour la découverte de vulnérabilités. Et ici on pensera à l’exemple que tu as mentionné de F-Secure, qui autorise le reverse engineering de ses produits dans ce cadre très spécifique.
François: Pour continuer la réflexion, est ce que tu aurais une ou des ressources à recommander aux auditeurs et auditrices à ce sujet-là?
Rayna: Le moment délicat de l’auto promo est arrivé. Je leur aurais bien dire de suivre mon flux Twitter à leurs risques et périls.
Rayna: Parce que je troll, donc je suis. Mais plus sérieusement, côté Yes We Hack, je me suis attaché avec l’aide très précieuse de mes collègues à faire des ressources justement sur ces sujets-là. Parce qu’on s’est rendu compte que ces sujets-là n’avancent pas assez vite. Ça n’avance pas aussi vite que la techno avance, que les technos avancent. Et donc, en fait, j’ai fait deux livres blancs, dont un vraiment très peu de technique, entre guillemets, parce que l’objectif n’était pas de parler outils, mais de parler “Pourquoi, Défis et opportunités, Niveau légal, niveau international, etc. Quelles sont les perceptions ? Quelles sont les avancées ?” Voilà. Ça c’était le premier qui est sur le blog de Yes We Hack. Il y a un onglet ressources et j’ai sorti le deuxième la semaine dernière. Donc, qui est cette fois un guide pas à pas, vraiment plus pratico-pratique, plus outillage, etc.
Rayna: Parce que il faut comprendre les défis, il faut comprendre les enjeux. Mais justement, si on veut que l’implémentation par un large nombre d’organisations ait lieu, il faut leur donner les moyens aussi. Ce deuxième est trouvable au même endroit sur le blog de Yes We Hack permet d’avoir beaucoup un guide, une ressource. C’est écrit petit, mais il y a beaucoup d’images.
François: Je rassure ceux qui nous une écoutent; Franchement, ça se lit très facilement. Le premier est super pédagogique pour quelqu’un qui n’y connait rien. Le sujet ? On découvre vraiment le contexte. Et pourquoi, finalement, même sans avoir à plonger en technique et bien comprendre les enjeux derrière, ça permet déjà de lancer la discussion. Ça rejoint ce que l’on a dit dans l’épisode, c’est avant tout un process, une de discussion. Aller voir des gens qui ne parlent pas le même langage que vous et se mettre d’accord sur la façon dont on va s’occuper de ses vulnérabilités lorsqu’elles nous viennent et si possible, d’y penser avant que ça nous tombe dessus. Pour que lorsque quelqu’un nous envoie un petit mail avec un prototype pour reproduire une attaque, un POC. Voilà, on puisse s’en servir et on puisse à cette personne pour dire déjà merci et on va s’occuper de ça le plus vite possible.
Rayna: C’est ça, mais c’est intéressant de voir quand on prend un peu de hauteur sur ce sujet de divulgation coordonnée. C’est comme avec le sexe enfaite, quand il y a de la bonne communication, il se passe des choses bonnes. Et bien là, c’est la même chose quand on va discuter avec les métiers, avec les autres collègues, même si effectivement, on a des approches qui sont parfois diamétralement opposées. La sécurité c’est No-As-A-Service, tu vois,
- Est-ce que je peux faire, ça ?
-Non.
- Est ce que je peux ouvrir tel flux ?
— Non.
Mais pourquoi en fait, on dit non ? Ça permet aussi de faire monter les gens en compétences ailleurs. En fait, pourquoi je te dis non ? Si je te dis juste non, bien sûr que ça va te frustrer, mais si je t’explique pourquoi je te dis non, peut être que tu trouveras des façons différentes de faire des choses. Peut-être plus élégante, peut-être plus simple que “vas-y, on ouvre les flux”. Il y a ça aussi. Perso, je ne sais pas vous, mais moi, je préfère être en d’être en bons termes avec mes collègues plutôt qu’être en tension avec eux en permanence. C’est très bête à dire. Par contre, ça demande effectivement d’aller voir les gens, de leur parler pro activement. Voilà, une bonne communication et de bonnes choses arrivent. C’est valable dans tous les domaines.
François: On va conclure sur cette magnifique comparaison. Cette métaphore filée. Merci beaucoup Rayna, pour cet échange. Je mettrai dans les notes de l’épisodes le lien vers les deux livres blancs que tu as proposés également ton handle twitter, On peut trouver sous le nom d’utilisatrice ?
Rayna: MaliciaRogue
François: MaliciaRogue. Merci beaucoup Rayna pour cet échange.
Rayna: Merci beaucoup à toi.
François: Et à très bientôt pour un prochain épisode de Post Mortem.
François: C’était le quatrième épisode de Post Mortem. J’espère qu’il vous a plu pour soutenir le podcast, n’hésitez pas à laisser une note et un commentaire sur Apple Podcasts, ça nous aide énormément. A une prochaine.
Notes de l'épisode
Que faire lorsque l’on rencontre une vulnérabilité dans un produit ou un service numérique?
On explore avec Rayna Stamboliyska (Twitter: @MaliciaRogue) le rôle de la divulgation coordonnée de vulnérabilités; en quoi celle-ci permet de fluidifier la remontée des vulnérabilités et offre un compromis intéressant pour préserver la sécurité des utilisateurs?
Dans un environnement où nous sommes tous utilisateurs finaux de produits et de services numérique, où le risque 0 en cyber sécurité n’existe pas, une organisation qui affiche une politique de divulgation coordonnée envoie un signal fort sur son humilité face au risque ainsi que sur le cheminement qu’elle a déjà effectué afin de limiter ce risque.
Après un tour d’horizon du cadre légal sur la divulgation de vulnérabilités, on passe en revue quelques organisations à partir desquelles s’inspirer pour la vulnerability disclosure. Enfin, Rayna nous partage ses bonnes pratiques pour la mise en place d’une politique de divulgation coordonnée de vulnérabilités.
Références mentionnées au cours de l’épisode:
Norme ISO 29147 — Divulgation de vulnérabilité — iso.org
Norme ISO 30111- Processus de traitement de la vulnérabilité — iso.org
Arguments pour / contre les différents types de divulgation — wikipedia.org
Loi du 7 octobre 2016 pour une République numérique, article 47 — legifrance.gouv.fr
Hall of fame de Nokia sur sa divulgation responsable — nokia.com
F-Secure Vulnerability Reward Program — f-secure.com
The EU Cybersecurity Act at a glance, from the european commission — ec.europa.eu