FAQ

CAPEC fournit une structure détaillée pour reproduire des scénarios d’attaque réalistes, ce qui en fait une ressource précieuse pour les simulations. Chaque modèle décrit les prérequis, les étapes d’exécution, les cibles, les vecteurs d’attaque, ainsi que les objectifs potentiels de l’attaquant. Cela permet aux équipes de sécurité de concevoir des exercices de red teaming ou de threat modeling bien cadrés.

Par exemple, un testeur peut choisir un modèle CAPEC d’attaque par bruteforce sur un service réseau et l’utiliser comme base pour évaluer la robustesse d’une application. Cette approche rend les tests plus cohérents et facilite la documentation des résultats et des recommandations.

Les CWE sont intégrées dans de nombreux outils d’analyse de code source, d’audit de sécurité ou de gestion des vulnérabilités, pour identifier automatiquement les faiblesses potentielles dans les logiciels. En comprenant quelles CWE sont présentes dans un système, les équipes peuvent estimer la surface d’attaque, anticiper les menaces futures, et prioriser les corrections avant qu’une faille ne devienne une CVE exploitable.

Elles permettent également d’établir des profils de risque pour des projets ou produits, en fonction de la nature et du nombre de faiblesses identifiées. Cela facilite la prise de décision pour les RSSI, DSI ou responsables de conformité, notamment dans les démarches DevSecOps ou lors d’évaluations selon des cadres comme NIST ou ISO 27002.

L’exploitation d’une zero-day repose sur le développement d’un exploit spécifique, c’est-à-dire un code ou une méthode capable de tirer parti de la faille avant qu’elle ne soit corrigée. L’attaquant peut l’intégrer dans un document piégé, un site web, un malware ou un email de phishing.

Une fois l’exploit lancé, il peut permettre de prendre le contrôle du système, d’installer un cheval de Troie, d’ouvrir une porte dérobée ou d’extraire des données. La particularité d’un exploit zero-day est qu’il échappe aux mécanismes de détection classiques, car il s’appuie sur une faiblesse encore inconnue de tous.

Le processus de publication d’une CVE commence généralement par la soumission d’un rapport de vulnérabilité à un CNA ou directement à MITRE. Si la faille est reconnue comme légitime, un identifiant CVE est réservé. À ce stade, la CVE peut rester "réservée" pendant un certain temps, en attendant la validation technique, l’accord des parties concernées ou la disponibilité d’un correctif.

Une fois toutes les informations vérifiées, la CVE est rendue publique via le site officiel de MITRE (cve.org) et d'autres plateformes comme NVD (National Vulnerability Database) ou CVE Find. Elle comprend une courte description technique de la vulnérabilité, la date de publication, les produits affectés et parfois des références vers des correctifs ou des avis de sécurité.

La CISA (Cybersecurity and Infrastructure Security Agency) est une agence gouvernementale américaine. Elle est chargée de protéger les infrastructures critiques des États-Unis contre les menaces cyber et physiques, en apportant du soutien, des outils, et des recommandations aux administrations, aux entreprises, et au public.

Dans le domaine de la cybersécurité, la CISA agit comme un centre de coordination pour prévenir les cyberattaques, réagir aux incidents, partager des informations sur les menaces, et promouvoir les meilleures pratiques de sécurité. Bien qu'américaine, son rôle et ses ressources influencent les pratiques de cybersécurité à l’échelle mondiale, en raison de sa transparence et de son leadership.

Une CWE (Common Weakness Enumeration) est une classification standardisée des faiblesses susceptibles de conduire à des vulnérabilités dans des logiciels, firmwares ou systèmes. Contrairement aux CVE, qui désignent des vulnérabilités spécifiques et documentées dans un produit donné, les CWE décrivent des types de défauts de conception ou de programmation pouvant affecter la sécurité d’un système.

Par exemple, une CWE peut décrire une mauvaise gestion de la mémoire, une injection de commande, ou encore une validation insuffisante des entrées. Ces faiblesses peuvent ensuite être détectées dans de multiples logiciels, et associées à des CVE individuelles si elles sont exploitées dans un contexte réel.

Les CWE sont des modèles abstraits de faiblesses, alors que les CVE sont des incidents concrets. Une CVE représente une vulnérabilité identifiée dans un logiciel ou un système précis, tandis qu’une CWE décrit une faiblesse générique présente dans le code ou l’architecture, sans forcément être exploitée.

Prenons un exemple : une CVE pourrait concerner une injection SQL dans une application web, tandis que la CWE correspondante serait CWE-89: Improper Neutralization of Special Elements used in an SQL Command. En résumé, les CWE servent à catégoriser et analyser les failles, alors que les CVE permettent de les suivre et les corriger individuellement.

L’EPSS complète le CVSS en apportant une dimension temporelle et comportementale à l’évaluation des vulnérabilités. Le CVSS mesure la gravité d’une faille sur la base de ses propriétés intrinsèques (impact, complexité, accessibilité), mais ne dit rien sur la probabilité réelle qu’elle soit exploitée. L’EPSS comble cette lacune en analysant des données issues du terrain, comme les tendances d’exploitation observées dans les honeypots, les moteurs de recherche de vulnérabilités, ou les flux de menace.

Cette complémentarité est précieuse pour la gestion des risques : une faille peut être critique selon le CVSS, mais non exploitée (score EPSS faible), ou au contraire apparaître bénigne en théorie, mais très utilisée dans des attaques automatisées. Utiliser les deux scores ensemble permet d’établir des priorités plus pertinentes et conformes à la réalité du terrain.

Non, l’EPSS ne remplace pas le CVSS : les deux systèmes sont complémentaires. Le CVSS donne une mesure structurelle de la gravité, utile pour comprendre l’impact potentiel d’une vulnérabilité. L’EPSS, quant à lui, fournit une mesure comportementale et prédictive, centrée sur la probabilité d’exploitation réelle.

Ensemble, ces deux scores permettent une évaluation plus fine du risque, à la fois sur le plan théorique et opérationnel. De nombreuses entreprises adoptent une approche hybride, par exemple en ne traitant que les vulnérabilités ayant à la fois un CVSS ≥ 7 et un EPSS ≥ 0.5, ou en utilisant des matrices de risques enrichies de ces deux indicateurs.

Non, l’existence d’une CVE ne garantit pas qu’un correctif soit disponible. Une CVE peut être publiée avant qu’un éditeur n’ait développé un correctif, ou même dans des cas où aucun correctif n’est prévu (par exemple, pour des logiciels obsolètes ou plus maintenus). Dans ces situations, les utilisateurs doivent mettre en place des mesures de contournement ou désactiver certaines fonctionnalités vulnérables.

Il est donc essentiel de ne pas seulement consulter les CVE, mais aussi de vérifier les recommandations des éditeurs et les bases comme la NVD ou la base KEV, qui peuvent indiquer si un patch existe et dans quels délais il est attendu. Une bonne gestion des risques prend en compte à la fois la gravité de la faille et la disponibilité de solutions.

Oui, il existe un calculateur officiel du score CVSS proposé par le Forum des standards FIRST, qui maintient le standard CVSS. Il est accessible en ligne à l’adresse : https://www.first.org/cvss/calculator.

Ce calculateur permet de composer un vecteur en sélectionnant les métriques pertinentes, puis de calculer automatiquement les scores (base, temporel, environnemental).

Oui, de plus en plus d’organisations utilisent l’EPSS comme critère prioritaire pour décider quelles vulnérabilités corriger en premier, en particulier lorsqu’elles font face à un grand volume de failles à traiter. Corriger toutes les CVE ayant un score CVSS élevé peut être coûteux et inefficace, surtout si certaines ne sont jamais exploitées. L’EPSS permet donc de focaliser les ressources sur les failles réellement dangereuses.

Certaines politiques de sécurité intègrent désormais des seuils d’action basés sur l’EPSS, par exemple : “corriger toute vulnérabilité ayant un score EPSS > 0.7 dans les 48h”. Cette approche pragmatique permet d’accélérer la remédiation là où c’est le plus utile, tout en limitant les interruptions non justifiées.

Non, les CVE ne concernent pas uniquement les logiciels. Elles peuvent aussi couvrir des vulnérabilités dans le matériel, les firmwares, les composants IoT, les systèmes d’exploitation, voire certaines configurations par défaut dangereuses. Par exemple, des failles dans les routeurs, processeurs ou équipements industriels peuvent également recevoir des identifiants CVE.

Cette couverture large permet de prendre en compte les différents vecteurs d’attaque dans un système d’information moderne. L’essentiel est que la vulnérabilité soit documentée, confirmée et publiquement signalée pour entrer dans le programme CVE. Ainsi, les équipes de sécurité peuvent évaluer les risques à l’échelle de toute l’infrastructure.

La liste KEV (Known Exploited Vulnerabilities) publiée par la CISA recense les vulnérabilités activement exploitées dans la nature, c’est-à-dire déjà utilisées dans des cyberattaques réelles. Cette liste a pour objectif d’aider les organisations à prioriser leurs efforts de correction, en se concentrant sur les failles qui représentent une menace immédiate.

En publiant cette liste, la CISA fournit un outil de gestion des risques très concret : elle signale non seulement les failles connues, mais aussi les plus critiques et les plus urgentes. Pour les agences fédérales américaines, la correction de ces failles est obligatoire dans des délais stricts. Mais au-delà des États-Unis, la KEV est largement consultée par les professionnels de la cybersécurité dans le monde entier pour orienter leur stratégie de patch management.

Le score CVSS mesure la gravité intrinsèque d’une vulnérabilité, mais pas son exploitation réelle, ni sa pertinence dans un environnement donné. Par exemple, une faille peut avoir un score élevé, mais être peu exploitable dans votre infrastructure, ou au contraire, une faille moyenne peut cibler un système critique non segmenté.

Pour une évaluation plus précise du risque, il est important d’intégrer des indicateurs complémentaires, comme :

• Le score EPSS (probabilité d’exploitation réelle)
• L’appartenance à la liste KEV (exploitation confirmée)
• Le contexte métier ou technique de l’environnement touché

Ainsi, le CVSS doit être vu comme un indicateur de gravité, et non une mesure complète du risque.