CVSS : une v4 plus précise pour noter les vulnérabilités logicielles

La v4 du framework CVSS (notation des vulnérabilités logicielles) a fait son entrée. Qu’apporte-t-elle par rapport à la version précédente de 2019 ?

Dans quelle mesure peut-on automatiser les attaques ? Les systèmes touchés peuvent-ils récupérer sans intervention humaine ? Quel niveau d’effort la réponse nécessite-t-elle ? Le CVSS (Common Vulnerability Scoring System) regroupe maintenant ces aspects dans une catégorie d’indicateurs spécifique.

Le framework se segmente désormais comme suit :

Les indicateurs « de base » correspondent aux qualités « intrinsèques » des vulnérabilités logicielles. Elles sont constantes.
Le deuxième groupe d’indicateurs – auravant appelé Temporal et renommé Threat – comprend les caractéristiques qui varient avec le temps. Le troisième (Environmental), celles qui dépendent de l’environnement.

La combinaison de ces trois groupes permet d’attribuer aux vulnérabilités une note de 0 à 10. Par défaut, le calcul se fonde sur un niveau de criticité maximal pour les indicateurs variables. Aux utilisateurs du framework de les modifier grâce notamment aux renseignements sur les menaces.

La version 3.1 du CVSS, sortie mi-2019, avait introduit le concept de la « complexité d’attaque ». Avec la v4, tout juste publiée, ce concept se divise désormais en deux dimensions. La « complexité d’attaque » caractérise les actions à mener pour contourner les mesures de sécurité intégrées (ASLR, DEP…). Les « prérequis d’attaque » englobent les conditions de déploiement, d’exécution ou les variables qui rendent l’attaque possible.
Cette approche doit permettre de noter distinguer des exploits jusqu’ici notés de la même manière malgré des conditions plus ou moins complexes (exemple : déjouer de la cryptographie vs itérer une attaque jusqu’à obtenir une situation de compétition).

La v4 du CVSS met aussi à jour l’indicateur « de base » relatif à l’interaction utilisateur, pour le rendre plus granulaire. Il peut dorénavant prendre trois valeurs :

– N (None) : système exploitable sans interaction humaine sinon celle de l’attaquant
– P (Passive) : nécessité d’une interaction limitée (considérée comme involontaire) de l’utilisateur ciblé avec le composant vulnérable et la charge utile
– A (Active) : exige des interactions spécifiques, conscientes ou qui sabotent activement des mécanismes de protection

Un supplément de contexte dans le CVSS

Le nouveau groupe d’indicateurs « supplémentaires » n’influe pas sur la notation, mais permet d’apporter du contexte. Il aborde six aspects :

– Sûreté
La vulnérabilité a-t-elle, au regard de la norme CEI 61508, des conséquences « négligeables » ? Ou, au contraire, « marginales », « critiques » ou « catastrophiques » ?

– Automatisation
Peut-on ou non automatiser les failles de reconnaissance, d’armement, de livraison et d’exploitation ?

– Urgence
Quel niveau d’urgence le fournisseur du logiciel a-t-il défini ?

– Récupération
Les systèmes touchés peuvent-ils récupérer automatiquement ? Faut-il une intervention manuelle ? La récupération est-elle impossible ?

– Densité de valeur
Les systèmes vulnérables ont-ils accès à peu ou beaucoup de ressources (exemple : client vs serveur) ?

– Effort de réponse
Qu’en coûte-t-il de remédier à la vulnérabilité ?

Autre évolution terminologique : on ne parle plus de « scopes », mais de « systèmes vulnérables » et de « systèmes subséquents ». Le principe, lui, ne change pas fondamentalement. Il s’agit toujours, comme depuis CVSS v3 (mai 2015), de faire la différence entre composants vulnérables et composants impactés. Exemple : une faille dans une VM permet de compromettre l’hôte.