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.
EPSS : une méthode créée en 2019 pour mettre en avant les vulnérabilités à la fois graves et exploitées
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 ?
Quel problème l’Exploit Prediction Scoring System cherche-t-il à résoudre ?
Dans leur présentation de la Black Hat, les créateurs de l’EPSS partent de plusieurs constats du marché, à savoir :
- Trop de vulnérabilités sont publiées par rapport à la quantité de vulnérabilités pouvant être traitées par les équipes de sécurité ;
- Moins de 5% des vulnérabilités sont réellement exploitées par des attaquants.
Ils mettent notamment en avant les conclusions d’une présentation de Luca Allodi et Fabio Massacci en 2013, qui indiquent que :
- Corriger les vulnérabilités de niveau élevé ou moyen et qui disposent de kits d’attaque automatiques améliore le niveau de sécurité de 62,81 % ;
- Corriger les vulnérabilités de niveau élevé ou moyen et qui disposent de démonstrations de kits d’attaque améliore le niveau de sécurité de 19,64% ;
- Corriger les vulnérabilités de niveau élevé ou moyen améliore le niveau de sécurité de 3,2%.
Quelle solution propose l’Exploit Prediction Scoring System ?
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 :
- Est-ce que la vulnérabilité dispose d’un kit d’attaque réellement utilisable (c’est-à-dire un exploit avec un excellent niveau de maturité technique) ?
- Est-ce que la vulnérabilité concerne un produit édité par Microsoft ?
- Est-ce que la vulnérabilité dispose d’un kit d’attaque public ?
- Est-ce que la vulnérabilité concerne un produit édité par Adobe ?
- Est-ce que la vulnérabilité est de type « Corruption de mémoire » ?
- Est-ce que la vulnérabilité concerne un produit édité par HP ?
- Est-ce que la vulnérabilité concerne un produit édité par Apache ?
- Est-ce que la vulnérabilité concerne un produit édité par IBM ?
- Est-ce que la vulnérabilité est de type « Exécution de code » ?
- Est-ce que la vulnérabilité est de type « Déni de service » ?
- Est-ce que la vulnérabilité peut être exécutée à distance ?
- Est-ce que la vulnérabilité concerne un service web ?
- Est-ce que la vulnérabilité est utilisable en local ?
- Est-ce que la vulnérabilité concerne un produit édité par Apple ?
- Est-ce que la vulnérabilité concerne un produit édité par Google ?
- Quel est le nombre de références associées à la vulnérabilité ?
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).
Cas pratique : calcul de l’Exploit Prediction Scoring System pour la CVE-2019-0708
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%.
L’Exploit Prediction Scoring System permet de calculer la probabilité d’exploitation d’une vulnérabilité et met en avant les vulnérabilités qui ont le plus de chance d’être utilisées sur le marché
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.
Le score EPSS donne un résultat semblable à une utilisation complète du standard CVSSv3.1 avec le critère temporel Exploit Code Maturity
Comparaison d’une approche score EPSS versus score CVSSv3.1 avec Exploit Code Maturity
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.
Analyse détaillée des différences de résultats entre EPSS et CVSSv3.1 avec Exploit Code Maturity
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 :
- Certaines CVE apparaissent dans les deux listes, comme CVE-2022-22965 (Spring4Shell), CVE-2021-44228 (Log4Shell), CVE-2019-11043 (vulnérabilité sur PHP FPM), CVE-2020-0796 (SMBGhost), CVE-2019-2725 (vulnérabilité sur Oracle WebLogic), et CVE-2019-0708 (BlueKeep)
- L’approche qui repose uniquement sur les critères du CVSSv3.1 fait ressortir la CVE-2020-1472 (Zerologon), la CVE-2018-17456 (vulnérabilité sur Git), la CVE-2021-31166 (vulnérabilité sur Microsoft Windows HTTP.sys), et la CVE-2020-9850 (vulnérabilité sur des produits Apple notamment Safari),
- L’approche qui repose sur le score EPSS fait apparaître en plus CVE-2021-40438 (vulnérabilité sur le composant Apache HTTP Server mod_proxy), CVE-2017-8464 (vulnérabilité sur Microsoft Windows), CVE-2017-0144 (une vulnérabilité de la série EternalBlue sur Microsoft Windows), et CVE-2017-0037 (vulnérabilité sur Microsoft Windows Internet Explorer et Edge).
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.
Quels sont les avantages et inconvénients de l’Exploit Prediction Scoring System ?
Le score EPSS est disponible plus rapidement que le score CVSS du NVD et fournit donc un premier niveau d’analyse d’une CVE récente : avantage EPSS
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 fait émerger des tendances fortes dans le système d’information : avantage EPSS
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.
L’Exploit Prediction Scoring System met en avant les vulnérabilités de certains constructeurs contrairement au CVSS qui est plus neutre : avantage CVSS
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.
qui montre que la vulnérabilité est activement exploitée
L’Exploit Prediction Scoring System est moins connu et reconnu pour le moment que le score CVSS : avantage CVSS
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é.
En conclusion, EPSS et CVSS sont des méthodes complémentaires et l’une ne saurait nullement remplacer l’autre
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.
Comment obtenir l’Exploit Prediction Scoring System de ses vulnérabilités ?
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.