Note : cet article traite de la version 1 du score EPSS. Depuis, une version 4 a été publiée avec des évolutions importantes. Pour en savoir plus sur EPSS v4, consultez notre article à jour 👉 EPSS v4
Si le score CVSS (Common Vulnerability Scoring System) est largement utilisé pour évaluer l’importance d’une vulnérabilité informatique, de nouvelles méthodes apparaissent régulièrement pour proposer d’étudier le même problème sous un autre angle. Cet article traite d’un score nommé EPSS, pour « Exploit Prediction Scoring System », qui indique la probabilité qu’une vulnérabilité soit exploitée.
Le score EPSS (Exploit Prediction Scoring System) a été créé en 2019 lors d’une présentation à la Black Hat (une célèbre conférence sur la sécurité informatique).
Ce projet, initié par les chercheurs Jay Jacobs, Sasha Romanosky, Benjamin Edwards, Michael Roytman, et Idris Adjerid, propose d’apporter une solution à un question fréquente en gestion des vulnérabilités : comment prioriser les vulnérabilités présentes dans un système d’information ?
Dans leur présentation de la Black Hat, les créateurs de l’EPSS partent de plusieurs constats du marché, à savoir :
Ils mettent notamment en avant les conclusions d’une présentation de Luca Allodi et Fabio Massacci en 2013, qui indiquent que :
Les inventeurs du score EPSS proposent de calculer pour chaque vulnérabilité la probabilité que celle-ci soit réellement utilisée sous 12 mois lors d’une attaque informatique.
Cette probabilité est calculée à partir des caractéristiques de chaque vulnérabilité, et d’un modèle de prédiction qui repose sur 16 variables :
A partir de ces 16 caractéristiques, et d’un modèle entraîné sur l’ensemble des CVE publiées dans la base MITRE, la formule suivante est établie.
LogOdds = -6.18 +
2.44 * vend:microsoft +
2.07 * vend:ibm +
2.00 * exp:weaponized +
1.91 * vend:adobe +
1.62 * vend:hp +
1.50 * exp:poc code +
1.10 * vend:apache +
1.01 * log(ref:count + 1) +
0.57 * tag:code execution +
0.23 * tag:remote +
0.22 * tag:denial of service +
0.06 * tag:web +
-0.20 * tag:memory corruption +
-0.63 * tag:local +
-0.89 * vend:google +
-1.92 * vend:apple
Pr[exploitation] = 1/(1+e^(-LogOdds))
Source : "Exploit Prediction Scoring System (EPSS)", Jacobs, Jay and Romanosky, Sasha and Edwards, Benjamin and Roytman, Michael and Adjerid, Idris, 2019, https://arxiv.org/abs/1908.04856Notons que ces caractéristiques peuvent changer dans le temps. Par exemple, les types d’exploits disponibles pour une CVE peuvent changer en fonction de l’intérêt des pirates. Cela fait que le score EPSS peut évoluer dans le temps. Le score EPSS est donc un score dynamique, là où le score CVSSv3.1 est plutôt utilisé comme un score statique (ce qui n’est pas tout à fait vrai, puisque le score CVSSv3.1 prévoit un critère « temporel », qui peut changer dans le temps, mais ce critère est rarement utilisé sur le marché sauf par des outils comme Cyberwatch Vulnerability Manager).
L’article qui présente l’EPSS donne un exemple avec la CVE-2019-0708 (BlueKeep). Les valeurs de chaque caractéristique sont :
La CVE-2019-0798 (BlueKeep) a donc un score CVSSv3.1 de 9,8/10, et un score EPSS de 95,2%.
Le principal intérêt du score EPSS est que l’écart des valeurs générées peut être très grand entre deux CVE. Visuellement, il est alors assez facile de distinguer des vulnérabilités qui méritent une attention immédiate.
Sur un échantillon de vulnérabilités liées à un parc informatique de démonstration, on peut ainsi tracer la répartition des CVE en fonction de leur score CVSSv3.1 de base et de leur score EPSS. Nous obtenons les graphes suivants.
La répartition des vulnérabilités en fonction de leur score EPSS fait immédiatement émerger une tendance là où une analyse qui se limite au score CVSSv3.1 de base ne permet pas de mettre en avant de vulnérabilités spécifiques.
Puisque le score EPSS donne des informations relatives à l’exploitabilité d’une vulnérabilité, il donne par essence des informations semblables à l’utilisation complète du standard CVSSv3.1 lorsque l’on prend en compte le critère temporel et notamment le critère « Exploit Code Maturity ».
Ce critère, noté « E » dans le standard CVSSv3.1, permet d’indiquer le niveau de maturité des kits d’attaques disponibles pour une vulnérabilité. Les vulnérabilités dont le niveau Exploit Code Maturity est à High sont les plus dangereuses car cela indique que le kit d’attaque est très simple à utiliser.
Un critère Exploit Code Maturity à Functional indique que le kit est disponible mais nécessite un peu d’effort de la part de l’attaquant. Tandis qu’une valeur à Proof-of-Concept indique que le kit est disponible mais ne fonctionne que si l’attaquant fournit un effort important pour adapter le code à sa cible.
Enfin, un critère à la valeur Unproven indique qu’aucun kit d’attaque n’est connu pour le moment.
Or, lorsque l’on prend en compte ce critère, et que l’on analyse les vulnérabilités d’un parc informatique classique, il apparaît que filtrer sur des vulnérabilités dont le score de base est critique (CVSSv3.1 de base supérieur ou égal à 9 sur 10) et dont l’Exploit Code Maturity vaut High, donne aussi une analyse très pertinente des actions prioritaires à mener dans le parc.
Cette approche montre notamment que 2,32% des vulnérabilités ont à la fois un score CVSSv3.1 critique et un Exploit Code Maturity à High.
Comparons maintenant les résultats des deux approches CVE par CVE, en retenant le top 10 de chaque méthode.
Les résultats des Top 10 des CVE avec chaque méthode figurent ci-après, les données venant d’un jeu de démonstration représentatif des systèmes d’information du marché.
Nous constatons que :
Dans les deux cas, certaines vulnérabilités marquantes ne sont pas retenues : la méthode « Top 10 du CVSSv3.1 critique avec Exploit Code Maturity élevé » ne permet pas de retenir la CVE-2017-0144 (membre de la série EternalBlue), tandis que la méthode « Top 10 des scores EPSS » ne retient pas la CVE-2020-1472 (Zerologon).
Aucune méthode n’est donc parfaite, et les deux approches sont mêmes complémentaires.
Le score CVSS du NVD repose sur les capacités d’évaluation des équipes du NIST. En pratique, il arrive que le score CVSS ne soit fourni par le NVD que plusieurs jours après la publication d’une CVE.
À l’inverse, le score EPSS est calculé à partir des formules mentionnées plus haut dans cet article. En conséquence, le score EPSS est fourni très rapidement et donne un premier aperçu de l’importance d’une nouvelle vulnérabilité.
Un exemple qui décrit très bien la situation est la CVE-2022-20477, publiée le 13 décembre 2022, dont le score CVSS n’est pas encore fourni par le NVD le 14 décembre 2022 à 13h00 heure de Paris, mais qui dispose déjà d’un score EPSS de 11,9%.
Le score EPSS varie fortement d’une CVE à une autre et permet de mettre en avant des tendances dans le système d’information. C’est ce que montre le graphe ci-dessous avec la distribution des CVE dont le score EPSS est le plus élevé sur un parc informatique de démonstration.
La formule de calcul du score EPSS met en avant, par construction, les vulnérabilités liées aux produits de Microsoft, IBM, Adobe, HP, Apache, Google, et Apple.
En conséquence, lorsqu’une vulnérabilité concerne une technologie différente de ces constructeurs, celle-ci aura un score EPSS assez faible.
C’est le cas de la CVE-2022-42475, qui concerne FortiOS, et qui est réellement exploitée et très dangereuse malgré un score EPSS faible.
Le score EPSS est récent, et est donc encore un projet en évolution et en construction. Cette méthode ne fait pas encore consensus, notamment en raison de l’absence de neutralité de ses inventeurs.
Jonathan Spring, membre du CERT/CC, indique ainsi dans son article « Probably Don’t Rely on EPSS Yet » que le modèle a été entraîné à partir de données issues de sondes AlienVault ou Fortinet, ce qui entraîne un biais, et que les vulnérabilités mentionnées comme activement exploitées dans la base du CISA KEV (CISA Known Exploited Vulnerabilities) ont de très faibles scores EPSS lorsqu’elles concernent l’Internet des Objets.
À l’inverse, le score CVSS est largement utilisé par la plupart des auditeurs du marché de la sécurité informatique, et la grande majorité des logiciels de l’industrie de la gestion des vulnérabilité.
Une analyse complète de la situation montre que le score EPSS n’est pas une formule magique qui peut remplacer le CVSS, mais plutôt une méthode complémentaire pour analyser les vulnérabilités d’un système d’information et qui peut être utile dans certaines situations.
Lorsqu’une vulnérabilité particulièrement récente n’a pas encore été évaluée par le NVD, et ne dispose pas de score CVSS, l’EPSS sera fort utile pour avoir un aperçu de la dangerosité de la CVE.
De même, il peut être pertinent d’analyser les actifs en fonction du score EPSS maximal détecté sur ces derniers, afin de faire émerger des tendances dans la système d’information.
Cependant, un score CVSSv3.1 bien utilisé, avec les critères temporels, voire même les critères environnementaux, permet tout aussi bien de prioriser ses risques avec une approche rationnelle et reconnue de l’ensemble du marché.
De plus, les analystes qui souhaitent utiliser des méthodes complémentaires au score CVSS pourront regarder la méthode MITRE ATT&CK, qui analyse les effets combinés de plusieurs CVE, cette méthode étant maintenant reconnue par le marché.
Enfin, si le CVSSv3.1 fait l’objet de critiques régulières, il ne faut pas oublier que ces critiques concernent exclusivement le score CVSSv3.1 de base, et que lors de l’utilisation complète du standard CVSSv3.1 avec les scores temporels et environnementaux la majorité des défauts disparaissent. Si quelques défauts subsistent, rappelons que ceux-ci sont en cours d’étude au sein du FIRST pour les corriger dans le cadre du futur score CVSSv4.0.
Cyberwatch Vulnerability Manager embarque une encyclopédie des vulnérabilités avec l’ensemble des scores EPSS disponibles, et permet de générer facilement des rapports centrés sur cette métrique.
N’hésitez pas à nous solliciter via notre formulaire de contact pour obtenir une démonstration.