Du CVSS au RBVM : enfin une priorisation des vulnérabilités efficace

Lorsqu’on découvre le CVSS (Common Vulnerability Scoring System), on peut facilement croire qu’il s’agit de l’outil idéal pour trier et prioriser les vulnérabilités. Un score plus élevé signifie forcément une vulnérabilité plus critique, non ? Et pourtant, cette logique ne tient pas la route. Chaque année, nous constatons une augmentation du nombre de vulnérabilités présentant des scores CVSS élevés. Les équipes de sécurité ne sont tout simplement pas en mesure de corriger toutes ces failles à temps, mais la grande majorité d’entre elles ne sont jamais exploitées dans des attaques réelles. Pendant ce temps, les pirates informatiques exploitent régulièrement des vulnérabilités moins visibles, mais à faible score. Il existe également d’autres pièges cachés, allant de problèmes purement techniques, comme des scores CVSS contradictoires, à des problèmes conceptuels, comme l’absence de contexte commercial.

Il ne s’agit pas nécessairement de lacunes du CVSS lui-même. Cela met plutôt en évidence la nécessité d’utiliser correctement cet outil, dans le cadre d’un processus plus sophistiqué et plus complet de gestion des vulnérabilités.

Incohérences du système CVSS

Avez-vous déjà remarqué qu’une même vulnérabilité peut avoir des scores de gravité différents selon la source disponible ? Un score attribué par le chercheur en cybersécurité qui a découvert la faille, un autre par le fournisseur du logiciel vulnérable, et encore un autre par une base de données nationale sur les vulnérabilités ? Il ne s’agit pas toujours d’une simple erreur. Parfois, différents experts peuvent être en désaccord sur le contexte d’exploitation. Ils peuvent avoir des idées différentes sur les privilèges avec lesquels une application vulnérable fonctionne, ou sur le fait qu’elle soit connectée à Internet ou non. Par exemple, un fournisseur peut fonder son évaluation sur ses meilleures pratiques recommandées, tandis qu’un chercheur en sécurité peut tenir compte de la manière dont les applications sont généralement configurées dans les organisations réelles. Un chercheur peut estimer que la complexité de l’exploitation est élevée, tandis qu’un autre la jugera faible. Ce genre de situation n’est pas rare. Une étude de 2023 réalisée par Vulncheck a révélé que 20 % des vulnérabilités répertoriées dans la base de données nationale sur les vulnérabilités (NVD) avaient deux scores CVSS3 provenant de sources différentes, et que 56 % de ces scores étaient contradictoires.

Erreurs courantes lors de l’utilisation du système CVSS

Depuis plus de dix ans, le forum FIRST milite en faveur d’une application correcte du CVSS sur le plan méthodologique. Pourtant, les organisations qui utilisent les notes CVSS dans leurs processus de gestion des vulnérabilités continuent de commettre des erreurs courantes :

1. Utilisation du score CVSS de base comme indicateur de risque principal. Le CVSS mesure la gravité d’une vulnérabilité, et non le moment où elle sera exploitée ou l’impact potentiel de son exploitation sur l’organisation attaquée. Dans certains cas, une vulnérabilité grave est inoffensive dans l’environnement d’une entreprise donnée parce qu’elle réside dans des systèmes insignifiants et isolés. À l’inverse, une attaque par ransomware à grande échelle peut commencer par une vulnérabilité de fuite d’informations à première vue inoffensive, avec un score CVSS de 6.
2. Utilisation du score CVSS de base sans tenir compte des facteurs de menace, temporels ou environnementaux. La disponibilité de correctifs, d’exploits publics et de mesures compensatoires détermine dans une large mesure le degré d’urgence et la manière dont une vulnérabilité doit être traitée.
3. Focalisation uniquement sur les vulnérabilités supérieures à un certain score. Cette approche est parfois imposée par les autorités gouvernementales ou les organismes de réglementation du secteur (« remédier aux vulnérabilités dont le score CVSS est supérieur à 8 dans un délai d’un mois »). Par conséquent, les équipes chargées de la cybersécurité sont confrontées à une charge de travail en constante augmentation qui, en réalité, ne protège pas davantage leur infrastructure. Le nombre de vulnérabilités identifiées chaque année avec un score CVSS élevé a augmenté rapidement au cours des dix dernières années.
4. Utilisation du CVSS pour évaluer la probabilité d’exploitation. Ces mesures sont peu corrélées : seules 17 % des vulnérabilités critiques sont réellement exploitées lors d’attaques.
5. Utilisation uniquement de la notation CVSS. La chaîne de vecteurs normalisée a été introduite dans le CVSS afin que les équipes de défense puissent comprendre les détails d’une vulnérabilité et calculer indépendamment son importance au sein de leur propre organisation. Le système CVSS 4.0 a été spécialement révisé pour faciliter la prise en compte du contexte commercial à l’aide de mesures supplémentaires. Tout effort de gestion de la vulnérabilité reposant uniquement sur une notation numérique sera en grande partie inefficace.
6. Non-prise en compte de sources d’informations supplémentaires. Il ne suffit pas de s’appuyer sur une seule base de données de vulnérabilités et d’analyser uniquement le CVSS. L’absence de données sur les correctifs, les preuves de concept fonctionnelles et les exemples d’exploitation réels rend difficile la prise de décision quant à la manière de traiter les vulnérabilités.

Les angles morts du CVSS face aux vulnérabilités

Le CVSS est la norme industrielle utilisée pour décrire la gravité d’une vulnérabilité, les conditions dans lesquelles elle peut être exploitée et son impact potentiel sur un système vulnérable. Cependant, au-delà de cette description (et du score de base CVSS), bien des aspects passent à la trappe :

• Qui a trouvé la vulnérabilité ? Était-ce le fournisseur, un chercheur éthique qui a signalé la faille en attendant un correctif, ou s’agissait-il d’un acteur malveillant ?
• Existe-t-il un exploit accessible au public ? Autrement dit, existe-t-il un code facilement accessible permettant d’exploiter cette vulnérabilité ?
• Est-il vraiment exploitable dans des conditions réelles ?
• Existe-t-il un correctif ? Couvre-t-il toutes les versions vulnérables du logiciel et quels sont les effets secondaires potentiels de son application ?
• L’entreprise doit-elle corriger la vulnérabilité ? Ou bien concerne-t-elle un service cloud (SaaS) dont le fournisseur assurera automatiquement la correction ?
• Existe-t-il des signes d’exploitation active ?
• Et si ce n’est pas le cas, quelle est la probabilité que cette vulnérabilité soit exploitée à l’avenir ?
• Quels sont les systèmes vulnérables au sein de votre organisation ?
• Un pirate informatique a-t-il une vraie chance d’exploiter cette faille ? Par exemple, il peut s’agir d’un serveur Web d’entreprise accessible en ligne, ou d’une imprimante vulnérable connectée physiquement à un seul ordinateur, sans aucun accès réseau. Un exemple plus complexe serait une vulnérabilité dans une méthode d’un composant logiciel, que l’application métier concernée n’appelle en réalité jamais.
• Que se passerait-il si les systèmes vulnérables étaient compromis ?
• Quel est le coût financier d’un tel événement pour l’entreprise ?

Tous ces facteurs influencent considérablement la décision quant au moment et à la manière de remédier à une vulnérabilité, voire même si une correction est réellement nécessaire.

Comment améliorer le CVSS ? La RBVM a la réponse !

De nombreux facteurs souvent difficiles à prendre en compte dans le cadre du CVSS sont au cœur d’une approche populaire connue sous le nom de gestion des vulnérabilités basée sur les risques (RBVM).

La RBVM est un processus holistique et cyclique, comportant plusieurs phases clés qui se répètent régulièrement :

• Inventaire de toutes les ressources informatiques de votre entreprise. Cela comprend tout, des ordinateurs, serveurs et logiciels, aux services cloud et aux appareils de l’IdO.
• Classement des ressources par ordre d’importance : identifiez vos principaux atouts.
• Analyse des ressources à la recherche de vulnérabilités connues.
• Enrichissement des données de vulnérabilité. Il s’agit notamment d’affiner les notations CVSS-B et CVSS-BT, d’intégrer la Threat Intelligence et d’évaluer la probabilité d’exploitation. Deux outils populaires pour évaluer l’exploitabilité sont l’EPSS (un autre score développé par le forum FIRST, qui indique la probabilité, en pourcentage, qu’une vulnérabilité soit exploitée dans le monde réel), et les bases de données comme la CISA KEV, qui recensent les vulnérabilités activement exploitées par des acteurs malveillants.
• Définition du contexte commercial : comprendre l’impact potentiel d’une exploitation sur les systèmes vulnérables, en tenant compte de leurs configurations et de leur utilisation au sein de votre organisation.
• Détermination de la manière dont la vulnérabilité peut être neutralisée par des correctifs ou des mesures compensatoires.
• La partie la plus intéressante : évaluation des risques pour l’entreprise et définition des priorités à partir de l’ensemble des données recueillies. Les vulnérabilités dont la probabilité d’exploitation est la plus élevée et qui peuvent entraîner des conséquences importantes sur vos ressources informatiques clés sont classées par ordre de priorité. Pour classer les vulnérabilités, vous pouvez soit calculer le CVSS-BTE, en incorporant toutes les données collectées dans la composante environnementale, soit utiliser d’autres méthodes de classement. Les aspects réglementaires influencent également l’établissement des priorités.
• Établissement de délais pour la résolution de chaque vulnérabilité en fonction de son niveau de risque et de considérations opérationnelles, comme le moment le plus propice pour effectuer les mises à jour. Si les mises à jour ou les correctifs ne sont pas disponibles, ou si leur mise en œuvre introduit de nouveaux risques et complexités, des mesures compensatoires sont adoptées au lieu d’une remédiation directe. Parfois, le coût de la correction d’une vulnérabilité l’emporte sur le risque qu’elle représente, et la décision peut être prise de ne pas y remédier du tout. Dans de tels cas, l’entreprise accepte consciemment les risques que la vulnérabilité soit exploitée.

En plus de ce dont nous avons discuté, il est essentiel d’analyser périodiquement le niveau de vulnérabilité de votre entreprise et de votre infrastructure informatique. À la suite de cette analyse, il convient de mettre en place des mesures de cybersécurité qui empêchent l’exploitation de classes entières de vulnérabilités ou qui renforcent considérablement la sécurité globale de systèmes informatiques spécifiques. Ces mesures peuvent inclure la micro-segmentation du réseau, la mise en œuvre du moindre privilège et l’adoption de stratégies de gestion des comptes plus strictes.

Un processus RBVM correctement mis en œuvre permet de réduire considérablement la charge qui pèse sur les équipes informatiques et de sécurité. Celles-ci consacrent leur temps de manière plus efficace, car leurs efforts sont principalement axés sur les menaces qui constituent une menace réelle pour l’entreprise. Pour comprendre l’ampleur de ces avantages en matière d’efficacité et d’économies de ressources, prenons l’exemple de cette étude menée par le forum FIRST. La hiérarchisation des vulnérabilités à l’aide du système EPSS seul permet de se concentrer sur à peine 3 % des vulnérabilités tout en obtenant une réussite de 65 %. En revanche, l’établissement de priorités en fonction de l’échelle CVSS-B nécessite de traiter 57 % des vulnérabilités, avec un taux d’efficacité de 4 %. Par « efficacité », on entend ici le fait de remédier correctement à des vulnérabilités qui ont effectivement été exploitées sur le terrain.