A propos de la divulgation coordonnée de vulnérabilités

0


Depuis un petit moment maintenant, de nombreuses sociétés et organisations tentent de trouver des solutions pour contrer le Bug Bounty sauvage (open bug bounty) ou encore empêcher le full disclosure qui consistent à révéler publiquement une faille de sécurité.

Vous connaissez aussi sans doute aussi le concept de “Divulgation Responsable” (Responsible Disclosure), qui reprend le concept du Full Disclo, à la différence prêt que cette fois, le découvreur de la faille laisse le temps à l’éditeur de publier un correctif.

Mais cela ne se passe pas toujours sans chamaillerie. En effet, les chercheurs souhaitent prévenir le plus vite possible la communauté de leur découverte et les éditeurs prennent souvent beaucoup de temps à proposer un correctif. Et pendant ce temps, le système impacté reste à la merci d’éventuels attaquants.

C’est la raison pour laquelle de nombreuses organisations plaident en faveur du concept de “Divulgation coordonnée de vulnérabilités” (DCV) afin de promouvoir et renforcer la coopération entre les différents acteurs de la cybersécurité qui tous ont un objectif commun : rendre l’Internet plus sûr.

Sur le blog de YesWeHack, nous avons publié un article à ce sujet, que je partage avec vous ici.

La Divulgation coordonnée de Vulnérabilités ( DCV ) est un processus visant à réduire les risques et in fine à atténuer les dommages potentiellement causés par une vulnérabilité ciblant un système d’information. La DCV ( CVD en anglais ) est un processus que l’on ne peut pas réduire au déploiement d’un correctif ou à la publication d’un rapport quand bien même ces événements sont des indicateurs de l’efficience de la coopération.

La divulgation coordonnée des vulnérabilités est donc le processus qui consiste à collecter des informations auprès des chercheurs de vulnérabilités, à coordonner le partage de ces informations entre les acteurs et à divulguer l’existence de vulnérabilités (logicielles, voire matérielles) et leurs mesures d’atténuation à diverses parties prenantes, y compris le grand public.

Cette pratique accroît de manière significative les chances de réussite de tout processus de réponse à vulnérabilité. Les contributions sont souvent des rapports de vulnérabilité rédigés par des chercheurs en sécurité.

Les rapports DCV concernant un produit (logiciel ou matériel) comprennent généralement des correctifs ainsi que des documents de rapport de vulnérabilité ou des enregistrements dans une base de données de vulnérabilités. Notez que de nombreuses vulnérabilités opérationnelles peuvent être aussi corrigées par l’opérateur et elles ne se traduisent pas forcément par une divulgation publique.

La divulgation des vulnérabilités est un processus par lequel les fournisseurs et les personnes qui découvrent des vulnérabilités peuvent travailler en collaboration pour trouver des solutions qui réduisent les risques associés à une vulnérabilité.

Norme ISO/CEI 29147 définissant la Divulgation de Vulnérabilités

Ce processus comprend des actions tels que le signalement, la coordination et la publication d’informations sur une vulnérabilité, son atténuation voire, dans l’idéal, sa résolution.

À ce stade, décortiquons la DCV :

Les principes:

  • Réduire les risques donc les dommages
  • Croire aux bonnes actions donc aux bons samaritains
  • Éviter le hasard
  • Stimuler la coopération
  • Suivre la déontologie
  • Apprendre de la boucle OODA
  • Considérer la DCV comme un processus naviguant entre le “meilleur” et le “pire”.

Les objectifs :

  • veiller à ce que les vulnérabilités identifiées soient prises en compte;
  • réduire au minimum le risque de vulnérabilité;
  • fournir aux utilisateurs suffisamment d’informations pour évaluer les risques liés aux vulnérabilités de leurs systèmes;

Les acteurs :

La Divulgation coordonnée de Vulnérabilités commence communément par la détection d’une vulnérabilité et se termine par le déploiement de correctifs ou d’atténuation.

Par conséquent, plusieurs acteurs sont impliqués dans le processus de CVD :

  • Chercheur en sécurité – la personne ou l’organisation qui identifie la vulnérabilité.
  • Rapporteur – la personne ou l’organisation qui avise le fournisseur de la vulnérabilité.
  • Fournisseur – la personne ou l’organisation qui a créé ou entretient le produit vulnérable.
  • Administrateur système – personne ou organisation qui doit déployer un correctif ou prendre d’autres mesures correctives.
  • Coordinateur – personne ou organisation qui facilite le processus d’intervention coordonnée.

Les étapes :

  • Découverte – Quelqu’un découvre une vulnérabilité dans un produit.
  • Rapport – Le fournisseur du produit ou un tiers coordinateur reçoit un rapport de vulnérabilité.
  • Qualification – Le destinataire d’un rapport le valide pour s’assurer de son exactitude avant de le prioriser en vue d’une action ultérieure.
  • Remédiation – Un plan d’assainissement (idéalement un correctif logiciel) est élaboré et mis à l’essai.
  • Sensibilisation du public – La vulnérabilité et les mesures correctrices sont divulguées au public.
  • Déploiement – Les mesures correctrices sont appliquées aux systèmes concernés.

La phase de rapport est importante, car elle requiert de créer des canaux sécurisés pour éviter que les informations transmises soient interceptées par une tierce partie.

Ce processus connaît cependant des obstacles :

  • Aucun contact du fournisseur disponible – Ceci peut se produire parce qu’un contact n’a pas pu être trouvé ou parce que le contact n’est pas réactif.
  • Cessation de coopération – les participants au processus de DCV pourraient avoir d’autres priorités qui attirent leur attention.
  • Fuites d’information – Qu’elles soient intentionnelles ou non, les informations destinées à un groupe restreint d’acteurs, peuvent être transmises à d’autres personnes qui ne participent pas au processus de DCV.
  • Découverte indépendante – Toute vulnérabilité qui peut être trouvée par un individu peut être trouvée par un autre, et tous ne vous en parleront pas.
  • Exploitation active – Les preuves qu’une vulnérabilité est activement exploitée par des adversaires nécessitent d’accélérer le processus de DCV pour réduire l’exposition des utilisateurs au risque.
  • La communication se détériore – La DCV est un processus de coordination d’activités humaines. En tant que tel, son succès dépend de la quatité des relations entre les participants.
  • Marketing – Dans certains cas, les vulnérabilités peuvent être utilisées comme un outil de marketing. Cela n’est pas toujours propice au bon déroulement du processus de DCV.

En synthèse :

Les pratiques de divulgation des vulnérabilités ne se limitent plus aux applications web. L’Internet des objets et la constellation de systèmes SCADA, d’appareils de santé connectés, de caméras de surveillance, de voitures connectées, de drones, etc. sont devenus tellement dépendants des logiciels et de l’Internet qu’ils augmentent le périmètre d’exposition et, de ce fait, seront inéluctablement exposés à de nouvelles attaques.

La Divulgation coordonnée de Vulnérabilités est une alliée majeure pour fédérer le plus grand nombre d’acteurs du cyberespace et stimuler l’échange de savoirs pour mieux assurer dès la conception : la sécurité et la protection de la vie privée.

En incitant à la coopération, la DCV permettra à tous les acteurs de la cybersécurité non seulement de défendre leurs bastions et leurs patrimoines informationnels, mais aussi de lutter plus efficacement contre le marché noir et/ou la revente de Zerodays.

Le décor est maintenant planté, alors passons de la théorie à la pratique.

Security.txt : la prometteuse RFC !

Afin de répondre au manque de contacts mis à disposition pour divulguer une vulnérabilité sur un site web , le chercheur en sécurité EdOverflow, bien inspiré par le rôle du fameux robots.txt, a suggéré depuis début août 2017 d’inclure dans chaque site web le fichier security.txt comme fichier de référence contenant la marche à suivre pour divulguer plus efficacement à l’éditeur d’un site un bug, une vulnérabilité.

Cette méthode a le mérite d’établir des lignes directrices claires pour les chercheurs en sécurité sur la façon de signaler les problèmes de sécurité et permet aux programmes de Bug Bounty de s’en inspirer pour mieux définir le périmètre d’attaque proposé aux futurs chercheurs.

Security.txt est une ébauche qui a été soumise à l’examen de la RFC. Cela signifie que security.txt en est encore aux premiers stades de développement. Vous pouvez y contribuer sur github !

Le Bug Bounty comme composant de votre politique de divulgation

Dans le cadre d’un développement agile sur leurs propres produits, de plus en plus de fournisseurs choisissent d’être pro-actifs en stimulant et en coopérant avec les chercheurs de vulnérabilités :

  • soit en misant sur les ressources et expertises en interne.
  • soit en contractant directement avec des chercheurs externes
  • soit en passant par une plateforme qui va mettre en relation des chercheurs et l’éditeur de la solution. Ce dernier paiera donc au résultat et pourra choisir différentes formules et options payantes telles que le management de programme voire le patch management si ses ressources en interne ne sont pas suffisantes.

La création et l’instauration dans la durée d’un programme de Bug Bounty sont considérées comme des indicateurs de maturité de la cybergouvernance des éditeurs en matière de vulnérabilité.

Depuis 2013, YesWeHack travaille au développement d’outils qui facilitent grandement la mise en place d’un politique incitative à la divulgation coordonnée de vulnérabilités. Sa communauté et son écosystème de services permettent aux organisations et aux chercheurs en sécurité informatique de mieux coopérer.

Grâce aux outils développés par YWG-H, les organisations bénéficiaires peuvent contourner plus aisément les obstacles rencontrés par leur politique de DCV. De plus, les organisations gagnent en notoriété en démontrant leur appétence et leur volonté d’améliorer en continu leurs systèmes.

Notre plateforme européenne de Bug Bounty a beaucoup d’avantages qui la rendent unique :

  • un recours à des partenaires et prestataires européens pour des questions de souveraineté.
  • une infrastructure légale et technique qui répond aux exigences de sécurité les plus élevées.
  • la sécurité et la confidentialité des communications basées sur le chiffrement et le respect des normes ISO.
  • une sécurisation des transactions financières entre les organisations et les chercheurs en sécurité.
  • une plateforme de paiement conforme aux dispositifs européens de lutte contre le blanchiment d’argent et contre le financement du terrorisme.
  • un accompagnement tout au long du processus : de la rédaction du programme jusqu’à l’aide aux correctifs.
  • un classement opérationnel des meilleurs chercheurs : Gestion d’une communauté de chercheurs en sécurité.
  • une réactivité qui permet de mobiliser les meilleurs chercheurs en un temps record.
  • une capacité d’organisation de différents types de programmes de Bug Bounty (Privé / public / In situ / Hardware et/ou Software).

Quelle démarche adopter si un produit ne propose ni Bug Bounty ni Security.txt ?

Il existe un outil simple et efficace pour éviter les remontées sauvages de vulnérabilités : Zerodisclo.com

Il est important de noter que certains produits (logiciel ou physique) ne disposent pas de leur propre programme de Bug Bounty. Il est ainsi délicat pour un chercheur en sécurité de pouvoir remonter une vulnérabilité à une société éditrice. Tous les pays ne disposent pas d’une loi permettant ce type de pratique comme c’est l’objet de l’article 47 de la Loi pour une République numérique initiée par l’ANSSI.

YesWeHack a crée Zerodisclo.com pour faciliter les remontées de vulnérabilités de façon sécurisée, voire anonyme, et ainsi mettre en relation les différents acteurs œuvrant pour un Internet plus sûr. Grâce à Zerodisclo plusieurs obstacles sont levés : Pas de login, anonymisation du rapport via le réseau Tor (.onion) et chiffrement obligatoire et automatique du contenu du rapport avec la clef PGP publique du CERT choisi. Vous pouvez consulter la liste des CERTs inclus dans ZeroDisclo.com

À titre d’exemple : vous pouvez aussi rapporter directement au CERT FR en cliquant sur le lien suivant > https://zerodisclo.com/#cert-fr

J’espère que certe article vous aura aidé à y voir plus clair sur ce qu’est la Divulgation coordonnée de Vulnérabilités et que cela vous aura donné envie de vous y mettre pour reprendre enfin le contrôle de vos vulnérabilités.

Conçue pour fonctionner à grande vitesse et offrir les plus faibles temps de latence possible, la Ballistix Tactical DDR4 constitue une avancée majeure dans le domaine de la mémoire standard pour jeux vidéo

La Ballistix Tactical DDR4 atteint des débits de l’ordre de 2 666 MT/s, assurant un gain appréciable en termes de réactivité et maniabilité du jeu et optimise la dissipation thermique, assurant une meilleure maintenace de votre matèriel



Source link


vous pourriez aussi aimer Plus d'articles de l'auteur

Laisser un commentaire

Votre adresse email ne sera pas publiée.