Quel est l'objectif du système des vulnérabilités et expositions communes (CVE) du point de vue de la sécurité ?

Contexte et objectif de l'article de blog

Au sein de l’équipe Intrusion et Sécurité des Applications (appelée IAS pour le reste de l’article), nous découvrons et publions des vulnérabilités identifiées dans des produits commerciaux presque chaque année depuis 2015. Ce processus est réalisé via le système des vulnérabilités et expositions communes (CVE).

Avec le temps, nous avons été confrontés à différents types de problèmes ainsi qu’à des incompréhensions dans le processus de publication. C’est pourquoi nous avons décidé de créer un article de blog, sous forme de FAQ, afin de :

1️⃣ Offrir une meilleure compréhension du système CVE.

2️⃣ Jouer les MythBusters en démystifiant certains mythes liés aux CVE.

3️⃣ Être transparents et précis sur la manière dont nous traitons une vulnérabilité que nous identifions dans un logiciel (web, mobile, desktop…).

💡 Le contenu de cet article est basé sur notre expérience et sur le processus de divulgation responsable que nous suivons, avec le soutien préalable du CSIRT de Thales.

🌎 Ce processus est public.

Quelques définitions

Les termes suivants ont été utilisés dans cet article :

◾ Common Vulnerabilities and Exposures (CVE): Système fournissant une méthode de référence pour les vulnérabilités et expositions en sécurité informatique connues publiquement (source).

◾ Vulnérabilité : Failles dans un système informatique qui affaiblissent la sécurité globale de l’appareil ou du système (source). Dans cet article, nous nous concentrons sur les failles affectant les logiciels.

◾ Exploit: Information et/ou morceau de code permettant d’exploiter une vulnérabilité.

◾ Base de données mondiale CVE : Registre global des enregistrements CVE géré par la société MITRE (plus d’informations).

◾ Identifiant CVE : Chaîne de caractères identifiant de manière unique une vulnérabilité référencée dans la base de données mondiale CVE.

          ▪️ Son format est “CVE-[Année]-[NuméroUniqueDansL’Année]”

➡️ Année : Partie correspondant à l’année de réservation de l’identifiant CVE ou à l’année de publication de la vulnérabilité.

 ➡️ NuméroUniqueDansL’Année: Identifiant unique du CVE pour l’année donnée.

          ▪️ Exemple: CVE-2022-38481

◾ Vendor: Entité développant, commercialisant et maintenant le logiciel affecté par la vulnérabilité identifiée.

◾ Scanners de vulnérabilités : Outils précieux qui recherchent et signalent les vulnérabilités connues présentes dans l’infrastructure informatique d’une organisation (source).

◾ Computer Security Incident Response Team (CSIRT): Capacité mise en place pour aider à répondre aux incidents liés à la sécurité informatique (source).

◾ IAS: Équipe Intrusion et Sécurité des Applications de Thales (homepage).

◾ TCS-CERT: CSIRT de Thales (homepage).

◾ Période de grâce : Durée, en jours, accordée à un éditeur pour créer un correctif pour la vulnérabilité. Elle est fixée à environ 100 jours et est explicitement documentée dans le processus de divulgation responsable que nous suivons. En cas de besoin, l’éditeur peut demander une extension de cette période pour mettre en œuvre une solution adéquate.

◾ Formulaire de demande CVE : Document standardisé contenant toutes les informations relatives à une vulnérabilité. Ce document est destiné à être envoyé à l’éditeur du logiciel concerné.

Questions fréquemment posées

Qu'est-ce que le système CVE et pourquoi existe-t-il ?

Le processus CVE (Common Vulnerabilities and Exposures) est une méthode standardisée permettant d’identifier et de nommer les vulnérabilités en cybersécurité. Il attribue un identifiant unique à chaque vulnérabilité, accompagné d’une description détaillée du problème et d’informations sur les moyens de réduire le risque.

Presque tous les outils d’analyse de vulnérabilités utilisent la base de données mondiale CVE pour identifier les produits vulnérables. Cela permet aux entreprises de repérer les produits affectés par des vulnérabilités, même si le fournisseur du produit n'a pas informé ses clients.

🧾 Exemple d'utilisation du CVE par : 

◾ Un outil gratuit d’analyse de vulnérabilités.

◾ Un outil commercial d’analyse de vulnérabilités.

En utilisant le processus CVE, les organisations peuvent rester informées des menaces potentielles en matière de sécurité et prendre des mesures pour y remédier avant qu’elles ne soient exploitées par des attaquants.

Quel est le lien entre la présence d’identifiants CVE et un logiciel ?

En 2023, on peut dire que si un produit ne possède aucun CVE enregistré dans la base de données mondiale CVE, cela est fortement suspect… En effet, les produits sont inévitablement affectés par des vulnérabilités au fil du temps, ce qui est tout à fait attendu.

😉 Mythe brisé ➡️ Aucun logiciel n'est 100 % sécurisé !

La présence de CVE sur un produit démontre la capacité et la conscience d’un fournisseur concernant la sécurité de ses produits. Cela montre que le fournisseur dispose d’un processus pour :

1️⃣ Recevoir les notifications de vulnérabilités.

2️⃣ Les traiter et les corriger.

3️⃣ Communiquer avec les clients et partenaires pour les alerter et les aider à appliquer les correctifs.

📡 Il s'agit d'un indicateur clair et explicite de :

1️⃣ Maturité du point de vue de la cybersécurité.

2️⃣ Honnêteté dans le sens où les vulnérabilités ne sont pas « cachées sous le tapis » !

3️⃣ Maîtrise de la posture de sécurité de vos produits.

4️⃣ Capacité de réction en cas de découverte d'une vulnérabilité sur un produit.

📍 À titre d’exemple, certaines entreprises pour lesquelles la présence de CVE sur leurs produits n’a pas compromis leur modèle économique ni la confiance de leurs clients (en avril 2023) :

L'entreprise Microsoft with around 9500 CVE sur ses produits.

L'entreprise Zoho with around 418 CVE sur ses produits.

L'entreprise Ivanti with around 70 CVE sur ses produits.

D'autres entreprises digurant sur cette page. 

Les descriptions CVE peuvent être un bon indicateur pour évaluer comment un fournisseur de produit considère les aspects liés à la sécurité :

❌ Si les différents CVE indiquent que le fournisseur n’a pas répondu aux notifications du CSIRT ou refuse de corriger la vulnérabilité, cela montre qu’il cherche à « cacher la vulnérabilité sous le tapis ». Il est donc fortement conseillé d'éviter ce fournisseur et sa gamme de produits!

✅ Si les différents CVE mentionnent un correctif ou une solution de contournement, c’est tout l’inverse ! Cela montre que le fournisseur prend la sécurité de ses produits au sérieux et met en place des mesures pour y remédier.

💡 Cela peut même être utilisé comme élément différenciateur par rapport à la concurrence, dans le sens où le fournisseur traite la sécurité de ses produits de manière professionnelle, transparente et rigoureuse.

Quels sont nos engagements en tant que fournisseur de solutions de sécurité ?

Les consultants en charge des évaluations de vulnérabilités et de la réponse aux incidents doivent suivre des pratiques éthiques. Ils s’engagent à protéger leurs clients ainsi que tous les autres utilisateurs de logiciels affectés par des vulnérabilités susceptibles de mettre les entreprises en danger.

Les membres de l’équipe Intrusion & Application Security suivent un code de conduite obligatoire qui décrit la manière dont les vulnérabilités identifiées dans des logiciels commerciaux doivent être traitées.

Le TCS-CERT est une équipe accréditée par Trusted Introducer (TI) et doit respecter son Code de conduite. Il applique une politique de divulgation responsable pour le traitement des vulnérabilités de sécurité.

Dans quel contexte un processus CVE est-il initié ?

1️⃣ Thales évalue un logiciel commercial dans le cadre d’une mission pour un client, ou directement pour le fournisseur de la solution. Des vulnérabilités peuvent également être découvertes en dehors de missions client, lors de travaux de R&D sur des logiciels disponibles publiquement (qu’ils soient propriétaires ou open source).

2️⃣ Une vulnérabilité jusqu'alors inconnue est identifiée dans le logiciel.

3️⃣ La vulnérabilité est présente dans la configuration par défaut du logiciel.

4️⃣ Le logiciel est utilisé par d'autres clients, qui sont donc exposés aux mêmes risques.

Quelle est la vue d’ensemble générale de ce processus ?

Qu’est-ce qui est partagé par Thales avec le fournisseur du logiciel ?

Le formulaire CVE, partagé de manière privée avec notre client et le fournisseur du logiciel, contient le score, les détails ainsi que nos recommandations pour corriger le problème. Ce formulaire doit inclure des informations précises pour aider le fournisseur à résoudre les vulnérabilités, mais ces détails ne sont jamais divulgués publiquement par Thales. Le formulaire comporte deux sections distinctes : Les éléments qui seront publiés et les éléments qui ne seront pas publiés par Thales.

Lorsque des accords de non-divulgation (NDA) sont signés entre le client, Thales et le fournisseur du logiciel, cela signifie que la divulgation de données applicatives, d’informations personnelles identifiables (PII) ou de détails sur l’infrastructure ne peut être partagée avec des tiers. Thales veille toujours à ce que les données applicatives, les PII et les détails de déploiement (adresses IP, URLs) ne soient jamais communiqués au fournisseur du logiciel durant le processus CVE.

Cependant, les NDA ne visent pas à empêcher Thales de collaborer avec le fournisseur pour la mise en œuvre des correctifs, ni à empêcher la publication d’un ensemble minimal d’informations sur les vulnérabilités et l’historique du processus CVE (voir section suivante).

Qu’est-ce qui est publié par Thales ?

L’identifiant CVE et les informations générales associées (décrites ci-dessous) sont publiés sur le site web de Thales lorsque la vulnérabilité est corrigée, ou à l’échéance de la période de 90 jours (selon ce qui survient en premier) :

1️⃣ Le type de vulnérabilité, par exemple : « L’application est sujette à une attaque de type Cross-site Scripting (XSS) réfléchie sur plusieurs fonctionnalités. Cette vulnérabilité permet à un attaquant d’agir au nom des utilisateurs et d’exfiltrer des données. »

2️⃣ La sévérité de la vulnérabilité, selon le système de notation CVSS v3.

3️⃣ La plage de versions affectées.

4️⃣ Le correctif ou la solution de contournement à appliquer.

5️⃣ Le “Vulnerability Disclosure Timeline” qui retrace tous les événements de communication.

🧾 Exemple de CVE advisory que nous avons publié.

Qu’est-ce qui n’est pas publié par Thales ?

Il existe de nombreuses idées reçues sur le niveau d’information divulgué à la fin du processus CVE. Selon le contexte, certains chercheurs en sécurité peuvent choisir de divulguer plus d’informations que nécessaire.

Chez Thales, nous avons fait le choix de ne jamais partager d’informations techniques détaillées, afin de ne pas mettre en danger les utilisateurs de logiciels vulnérables. En effet, certaines entreprises utilisant ces logiciels peuvent ne pas être en mesure de les corriger pour diverses raisons (ignorance du problème, manque de temps, contraintes financières ou techniques…).

Par conséquent, les éléments suivants ne sont jamais publiés par Thales :

◾ Le nom du client (lorsque la vulnérabilité est découverte dans le cadre d’une mission).

◾ Les détails techniques de la vulnérabilité (emplacement et méthode d’exploitation).

◾ L’impact détaillé de la vulnérabilité.

◾ Les noms des personnes et le contenu des échanges avec le fournisseur du logiciel. 

◾ Un exploit permettant à quiconque d’utiliser ou d’abuser de la vulnérabilité.

Quels sont les obstacles généraux du processus CVE ?

Malgré les avantages évidents du processus CVE, certaines organisations peuvent hésiter à y participer, par crainte d’un impact potentiel sur leur image.

Si un fournisseur de logiciel tente d’empêcher Thales de publier des CVE, cela indique qu’il n’a pas confiance dans la sécurité de ses produits. Les clients devraient alors approfondir leur enquête pour garantir la sécurité de leurs systèmes.

Voici les points de blocage les plus fréquents dans le processus de publication :

Le fournisseur ne répond pas aux sollicitations de notre CSIRT

Le TCS-CERT tente alors de trouver un canal plus direct (comme le téléphone). Si aucune réponse n’est obtenue après plusieurs tentatives, l’équipe attend la fin de la période de grâce et publie le CVE en mentionnant l’absence de réponse du fournisseur dans la section “Vulnerability Disclosure Timeline” du CVE.

Le fournisseur conteste la nature de la vulnérabilité signalée

Dans ce cas, nous tentons d’expliquer la vulnérabilité et le risque d’un point de vue technique, de manière pédagogique, avec des preuves de concept, des appels techniques, etc.

Si, malgré tous nos efforts, le fournisseur refuse de corriger la vulnérabilité, alors le TCS-CERT attend la fin de la période de grâce et publie le CVE en mentionnant la posture du fournisseur dans la “Vulnerability Disclosure Timeline”.

📍 Si, au cours d’un échange avec le fournisseur, nous découvrons que la vulnérabilité est en réalité une “fonctionnalité intégrée”, alors nous pouvons décider d’annuler le processus CVE. Le fournisseur doit alors mentionner explicitement les risques liés à l’utilisation de cette fonctionnalité dans sa documentation.

🛡 Dans tous les cas, nous veillons à ce qu’une vulnérabilité identifiée ne soit jamais “cachée sous le tapis” par un fournisseur !

Le fournisseur a besoin de plus de temps pour corriger le problème

Lorsqu’un canal de communication honnête et transparent est établi, nous attendons le temps nécessaire au fournisseur pour publier un correctif efficace. Si le fournisseur le demande, nous pouvons tester le correctif afin de nous assurer de son efficacité.

📍 Pour aider le fournisseur, l’équipe IAS fournit toujours des conseils techniques détaillés pour corriger la vulnérabilité identifiée, dans le formulaire de demande CVE destiné au fournisseur.

Le fournisseur menace d’engager des poursuites judiciaires en cas de publication

Certains fournisseurs peuvent réagir de manière défensive, voire menacer d’actions en justice lorsqu’ils reçoivent des rapports de vulnérabilité. Cette réaction peut être liée à des craintes concernant leur réputation, des pertes financières, ou le risque d’exploitation de la vulnérabilité par des acteurs malveillants. Leurs raisons sont généralement l’une ou plusieurs des suivantes :

1️⃣ Atteinte à la réputation : La divulgation publique de vulnérabilités peut ternir l’image du fournisseur et affaiblir la confiance des clients, ce qui peut impacter négativement les ventes et la fidélité à la marque.

2️⃣ Préoccupations financières : Les fournisseurs peuvent craindre que la reconnaissance publique de vulnérabilités entraîne des responsabilités financières, y compris des actions en justice ou une perte de contrats.

3️⃣ Correction dans les délais : Les fournisseurs peuvent vouloir contrôler le processus de divulgation afin de disposer du temps nécessaire pour développer et déployer les correctifs avant que la vulnérabilité ne soit largement connue.

Malgré les difficultés, la divulgation responsable des vulnérabilités reste essentielle pour plusieurs raisons :

1️⃣ Protection des utilisateurs : Corriger rapidement les vulnérabilités permet de protéger les utilisateurs contre toute exploitation potentielle et de sécuriser leurs données sensibles.

2️⃣ Sécurité collaborative : En adoptant une démarche de divulgation responsable, les fournisseurs peuvent établir une relation de collaboration avec la communauté cybersécurité, ce qui conduit à des produits plus robustes et à de meilleures pratiques de sécurité.

3️⃣ Conformité réglementaire : Mettre l’accent sur la divulgation responsable est en adéquation avec les normes du secteur et peut aider les fournisseurs à répondre aux exigences de conformité.

4️⃣ Perception publique : L’engagement d’un fournisseur à traiter les vulnérabilités de manière responsable peut renforcer sa réputation en tant qu’organisation soucieuse de la sécurité.

🤝 Dans ce type de situation, Thales cherche toujours à dialoguer avec le fournisseur pour comprendre le problème et trouver une solution constructive. Cependant, les menaces ne pourront jamais empêcher la publication du CVE.

Que pouvez-vous faire en tant que fournisseur pour être prêt en cas de découverte de vulnérabilités ?

Créer un environnement qui encourage la divulgation responsable des vulnérabilités nécessite une collaboration et une compréhension mutuelle entre toutes les parties impliquées. Pour trouver le bon équilibre, les étapes suivantes sont essentielles :

1️⃣ Politiques claires : Les fournisseurs doivent établir des politiques claires de divulgation des vulnérabilités, précisant comment les chercheurs peuvent signaler les failles, et comment celles-ci seront reconnues et traitées.

2️⃣ Bug Bounty : Lorsqu’un haut niveau de confiance est atteint et que les processus sont transparents, la mise en place d’un programme de bug bounty peut inciter les chercheurs à signaler les vulnérabilités de manière responsable, tout en les protégeant contre d’éventuelles conséquences juridiques.

3️⃣ Communication : Une communication ouverte et respectueuse entre les fournisseurs et les chercheurs favorise la confiance et la coopération.

4️⃣ Reconnaissance : Les fournisseurs doivent reconnaître et valoriser les contributions des chercheurs qui signalent les vulnérabilités de manière responsable, en soulignant l’objectif commun d’amélioration de la cybersécurité.

Conclusion

En résumé, les CVE sont un outil essentiel pour maintenir la sécurité des systèmes logiciels. Ils favorisent la transparence, améliorent la qualité des logiciels, bénéficient à l’ensemble de la communauté de la sécurité et sont largement adoptés par l’industrie. Nous recommandons vivement aux organisations de prendre les CVE au sérieux et de les intégrer dans leur stratégie de sécurité.

Authors

▪️ Dominique Righetto

▪️ Julien Ehrhart