Présentation
L'acronyme CVE, pour Common Vulnerabilities and Exposures en anglais, désigne une liste publique de failles de sécurité informatique. Lorsque l'on parle d'une CVE, on fait généralement référence à une faille de sécurité à laquelle un identifiant CVE a été attribué.
Les avis de sécurité publiés par les fournisseurs et chercheurs mentionnent presque toujours au moins un identifiant CVE. Les CVE aident les professionnels à coordonner leurs efforts afin de hiérarchiser et résoudre les vulnérabilités, et ainsi de sécuriser au maximum les systèmes informatiques.
Fonctionnement du système des CVE
Organisme de recherche et de développement financé par le gouvernement des États-Unis, le MITRE a développé en 1999 le système CVE, une norme permettant de signaler et suivre les bogues de sécurité des logiciels de manière uniforme.
Les entrées de la liste CVE sont brèves. Elles ne comprennent pas de données techniques ni d'informations à propos des risques, des effets et des correctifs. Ces détails sont enregistrés dans d'autres bases de données, notamment dans la base de données NVD (National Vulnerability Database) des États-Unis ou la base de données CERT/CC Vulnerability Notes Database, ainsi que dans de nombreuses listes alimentées par des fournisseurs et d'autres organismes.
Les identifiants CVE inclus dans ces différents systèmes aident les utilisateurs à reconnaître les vulnérabilités, puis à coordonner le développement d'outils et de solutions de sécurité. L'organisme MITRE contrôle la liste CVE, mais ce sont souvent les entreprises et membres de la communauté Open Source qui signalent les problèmes de sécurité à l'origine des entrées CVE.
Identifiants CVE
Les identifiants CVE sont attribués par des autorités déléguées, les CNA (CVE Numbering Authority). Il existe environ 100 CNA, dont des entreprises de sécurité, des organismes de recherche et les principaux fournisseurs de services et produits informatiques (comme Red Hat, IBM, Cisco, Oracle et Microsoft). Le MITRE peut également émettre des CVE directement.
Le MITRE attribue aux CNA des blocs d'identifiants CVE, qui sont réservés et associés aux failles au moment de leur découverte. Des milliers d'identifiants CVE sont émis chaque année. Un seul produit complexe, tel qu'un système d'exploitation, peut cumuler des centaines de CVE. Il est donc particulièrement vulnérable lorsqu'il entre dans les phases de fin de prise en charge (lorsqu'il ne reçoit plus de correctifs) et de fin de vie (lorsque la prise en charge fournisseur s'arrête). Par exemple, lorsque CentOS Linux 7 a atteint sa fin de vie le 1er juillet 2024, une nouvelle CVE a été annoncée dans les heures qui ont suivi. Cette constatation souligne l'importance d'une migration vers un système d'exploitation stable qui fait l'objet de mises à jour et de correctifs de sécurité réguliers.
Un fournisseur, un chercheur ou même un utilisateur avisé peut découvrir une faille de sécurité et la signaler. De nombreux fournisseurs proposent des programmes de bug bounty qui encouragent et récompensent le signalement responsable des problèmes de sécurité. Si quelqu'un découvre une vulnérabilité dans un logiciel Open Source, il lui est vivement recommandé de la signaler à la communauté concernée.
D'une manière ou d'une autre, les informations concernant les failles finissent par parvenir jusqu'à une CNA. La CNA en question lui attribue alors un identifiant CVE, puis publie une nouvelle entrée sur le site web des CVE.
Souvent, les CNA attribuent un identifiant avant de rendre l'avis de sécurité public. Les fournisseurs se gardent généralement de révéler les failles de sécurité secrètes avant d'avoir développé et testé les correctifs, afin d'éviter que des cybercriminels ne les exploitent.
Une fois publique, une entrée de la liste CVE comprend un identifiant CVE (au format CVE-2019-1234567), une courte description de la vulnérabilité ou de la faille de sécurité, ainsi que des références, notamment des liens vers des rapports et des avis concernant la vulnérabilité.
Ressources Red Hat
Critères d'attribution d'un identifiant CVE
Conformément aux règles de fonctionnement de l'autorité de numérotation CVE, les identifiants CVE sont attribués à des failles qui répondent aux critères suivants :
- Possibilité de correction indépendante
Il doit être possible de corriger la faille indépendamment de tout autre bogue. - Reconnaissance par le fournisseur concerné ou documentation
L'éditeur de logiciel ou le fabricant de matériel doit reconnaître l'existence du bogue et son effet négatif sur la sécurité. L'utilisateur qui a signalé le bogue peut aussi partager un rapport de vulnérabilité qui permet de démontrer que le bogue a un effet négatif et qu'il enfreint la politique de sécurité du système touché. - Impact se limitant à un code base
Si la faille affecte d'autres produits, elle se voit attribuer une CVE pour chacun d'entre eux. Dans le cas de bibliothèques, protocoles ou normes partagés, la faille reçoit un seul identifiant CVE uniquement s'il n'existe aucun moyen d'utiliser le code partagé sans être affecté par la vulnérabilité. Sinon, chaque code base ou produit affecté obtient un identifiant CVE unique.
Définition du CVSS
Plusieurs systèmes permettent d'évaluer la gravité d'une vulnérabilité. Il existe notamment le système CVSS (Common Vulnerability Scoring System), un ensemble de normes ouvertes utilisées pour attribuer un nombre à une vulnérabilité afin d'en évaluer la gravité. Certaines bases de données, notamment NVD et CERT, utilisent ces scores CVSS pour évaluer les conséquences des vulnérabilités. Les scores sont compris entre 0 et 10, et les nombres les plus élevés correspondent à de hauts degrés de gravité. De nombreux fournisseurs de solutions de sécurité ont également créé leurs propres systèmes d'évaluation.
Trois points essentiels
Maîtriser les déploiements : l'apparition d'une faille ne signifie pas forcément que l'environnement et les déploiements sont exposés au risque. Il convient de lire chaque CVE pour vérifier si elle concerne (même partiellement) le système d'exploitation, les applications, les modules et les configurations de l'environnement.
Gérer les vulnérabilités : la gestion des vulnérabilités est un processus reproductible qui permet d'identifier, de classer, de hiérarchiser, de corriger et d'atténuer les vulnérabilités. Ce processus implique de comprendre comment une faille peut affecter l'entreprise, afin d'identifier les vulnérabilités qui doivent être corrigées en priorité.
Ne pas hésiter à communiquer : les failles et vulnérabilités auront des répercussions sur les systèmes, à cause des vulnérabilités elles-mêmes, mais également à cause des temps d'arrêt potentiellement nécessaires pour les corriger. Les entreprises doivent communiquer et collaborer avec leurs clients internes, et signaler les vulnérabilités via une fonction de gestion des risques centralisée.
Red Hat et les CVE
Contributeur majeur aux logiciels Open Source, Red Hat s'engage en continu auprès de la communauté des spécialistes de la sécurité. Red Hat est une CNA et utilise les identifiants CVE pour effectuer un suivi des vulnérabilités de sécurité. L'équipe Red Hat Product Security gère une base de données des avis de sécurité ouverte et fréquemment mise à jour, qu'il est possible de consulter pour rechercher un identifiant CVE. Par ailleurs, Red Hat continue de résoudre les CVE critiques et importantes pour les produits en fin de maintenance, tels que Red Hat Enterprise Linux 7, via son programme Extended Lifecycle Support.
API Red Hat Security Data
Sur le portail client Red Hat, l'équipe Red Hat Product Security publie des données de sécurité brutes et, à travers l'API Security Data, elle en fournit une version lisible par les machines.
En complément des rapports de sécurité et indicateurs de mesure fournis par Red Hat, les clients peuvent utiliser ces données brutes pour produire leurs indicateurs personnalisés.
L'API Security Data fournit notamment des définitions OVAL (Open Vulnerability and Assessment Language), des documents CVRF (Common Vulnerability Reporting Framework) et des données de CVE. Ces données sont disponibles aux formats XML et JSON.
Le blog officiel de Red Hat
Découvrez les dernières informations concernant notre écosystème de clients, partenaires et communautés.
