Jump to section

Une CVE, qu'est-ce que c'est ?

Copier l'URL

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 renforcer la sécurité des systèmes informatiques.

Pas envie de lire ? Regardez plutôt cette courte vidéo sur les CVE.

Le programme CVE est supervisé par l'organisme MITRE et subventionné par la CISA (Cybersecurity and Infrastructure Security Agency), qui fait partie du Département de la Sécurité intérieure des États-Unis.

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.

À propos des 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 qui représentent les principaux fournisseurs informatiques (comme Red Hat, IBM, Cisco, Oracle et Microsoft) ainsi que des entreprises de sécurité et des organismes de recherche.Le MITRE peut également émettre des CVE directement.

Les CNA disposent de blocs d'identifiants CVE alloués par le MITRE, qui sont réservés et attribués aux failles au moment de leur découverte. Des milliers d'identifiants CVE sont émis chaque année. Un seul produit complexe, un système d'exploitation par exemple, peut cumuler des centaines de CVE.

Les rapports de CVE peuvent avoir diverses origines : un fournisseur, un chercheur ou même un utilisateur avisé peut découvrir une faille 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 vous découvrez une vulnérabilité dans un logiciel Open Source, il est vivement recommandé de la signaler à la communauté.

D'une manière ou d'une autre, les informations concernant les failles finissent par parvenir jusqu'à une CNA. Celle-ci associe alors les informations reçues à un identifiant CVE, rédige une courte description et inclut des références. La nouvelle entrée est ensuite publiée sur le site web des CVE.

En général, un identifiant CVE est attribué avant la publication de l'avis de sécurité. Souvent, les fournisseurs ne révèlent pas l'existence d'une faille de sécurité tant qu'un correctif n'a pas été développé et testé. L'objectif est d'éviter qu'un cybercriminel n'exploite une faille non corrigée.

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é.

Les identifiants CVE sont attribués aux failles qui répondent à un ensemble de critères spécifiques :

1. Possibilité de correction indépendante

Chaque faille doit pouvoir être corrigée indépendamment de tout autre bogue.

2. Reconnaissance par le fournisseur concerné OU documentation

L'éditeur de logiciel ou le fabricant de matériel doit reconnaître le bogue et son effet négatif sur la sécurité. La personne 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é.

3. Impact sur un code base

Les failles qui touchent plus d'un produit doivent recevoir différents identifiants CVE. 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é. Dans le cas contraire, chaque code base ou produit affecté obtient un identifiant CVE unique.

D'après le contenu de la page : https://cve.mitre.org/cve/cna/rules.html#Appendix_C

Suivez l'actualité liée à la sécurité avec Red Hat.

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é. Les scores CVSS servent aux bases de données NVD et CERT, entre autres, 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é pour une vulnérabilité. De nombreux fournisseurs de solutions de sécurité ont également créé leurs propres systèmes d'évaluation.

Trois points essentiels

Maîtrisez vos déploiements : l'apparition d'une faille ne signifie pas forcément que votre environnement et vos déploiements sont exposés au risque. Lisez attentivement chaque entrée de la liste CVE afin de comprendre si la faille vous concerne en vérifiant si elle touche (même partiellement) le système d'exploitation, l'application, les modules et les configurations de votre environnement.

Gérez 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 votre entreprise, afin d'identifier les vulnérabilités qui doivent être corrigées en priorité.

N'hésitez pas à communiquer : les failles et vulnérabilités auront un impact sur les systèmes de votre entreprise, à cause des vulnérabilités elles-mêmes, mais également à cause des temps d'arrêt potentiellement nécessaires pour les corriger. Communiquez et collaborez avec vos clients internes. Signalez les vulnérabilités au sein de votre entreprise via une fonction de gestion des risques centralisée.

Red Hat et les CVE

En tant que 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 (CVE Numbering Authority) et utilise les identifiants CVE pour effectuer un suivi des vulnérabilités de sécurité. L'équipe Red Hat Security gère une base de données des avis de sécurité ouverte et fréquemment mise à jour, que vous pouvez consulter pour rechercher un identifiant CVE.

Sur sa page Security Data, 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 propres 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.

Découvrez l'approche de Red Hat en matière de sécurité et de conformité

Keep reading

ARTICLE

Le DevSecOps, qu'est-ce que c'est ?

Si vous souhaitez tirer pleinement parti de l'agilité et de la réactivité d'une approche DevOps, vous devez également intégrer la sécurité informatique au cycle de vie complet de vos applications.

ARTICLE

Quelles sont les spécificités de la sécurité dans le cloud ?

Les préoccupations en matière de sécurité de haut niveau affectent les systèmes informatiques traditionnels et cloud. Découvrez quelles sont les différences.

ARTICLE

Le SOAR, qu'est-ce que c'est ?

Le SOAR fait référence à trois capacités logicielles clés qu'utilisent les équipes de sécurité : la gestion des cas et des workflows, l'automatisation des tâches et la centralisation de l'accès, de l'interrogation et du partage des renseignements sur les menaces.

En savoir plus sur la sécurité

Produits

Structure de sécurité qui gère les identités des utilisateurs et préserve la confidentialité des communications.

Solution de sécurisation des conteneurs native pour Kubernetes et adaptée aux entreprises, qui permet de créer, de déployer et d'exécuter des applications cloud-native de manière sécurisée.

Service d'analyses prédictives qui aide à identifier et à écarter les menaces qui compromettent la sécurité, les performances et la disponibilité de votre infrastructure Red Hat.

Console unique pour le contrôle des clusters et applications Kubernetes, avec des politiques de sécurité intégrées.

Ressources