Le système de notation de la sévérité des vulnérabilités (CVSS) est désormais bien connu. Même si sa version 4.0 a été présentée par le FIRST (Forum of Incident Response and Security Teams, forum mondial d’équipes de réponse aux incidents et de sécurité) début novembre 2023, le principe de base est inchangé : chaque vulnérabilité se voit attribuer un score de 1 à 10, ce dernier représentant le niveau de sévérité le plus élevé. 

Certes, selon le communiqué de presse du FIRST, « la norme révisée offre une granularité plus fine dans les mesures de base pour les consommateurs, supprime l’ambiguïté de la notation en aval, simplifie les mesures de menace et améliore l’efficacité de l’évaluation des exigences de sécurité spécifiques à l’environnement ainsi que des contrôles compensatoires ». 

CVSS 4.0 apporte en outre « plusieurs mesures supplémentaires pour l’évaluation des vulnérabilités […], notamment la possibilité d’automatisation, la récupération, la densité de valeur, l’effort de réponse aux vulnérabilités et l’urgence pour le fournisseur », et s’ouvre aux univers OT/ICS et IoT. 

Cette version 4.0 du CVSS devrait notamment aider chacun à tenir compte de facteurs tels que la disponibilité d’un démonstrateur d’exploitation ou de la connaissance d’une exploitation active. Et ce n’est pas anodin.

Toutes les vulnérabilités ne se valent pas

De fait, appliquer les correctifs pour une vulnérabilité facilement exploitable, de l’extérieur, affectant un système exposé sur Internet, permettant l’accès à des ressources internes au système d’information, et pour laquelle un démonstrateur d’exploitation est disponible publiquement, s’avère particulièrement urgent. 

Si la vulnérabilité n’est exploitable que de l’intérieur du réseau et qu’aucune exploitation n’est aisément faisable, appliquer les correctifs peut être considéré comme moins urgent.

Le FIRST a d’ailleurs mis au point un système de notation de la probabilité d’exploitation d’une vulnérabilité connue à 30 jours, l’EPSS (ou Exploit Prediction Scoring System, en anglais), afin d’aider à la prise de décision.

Le catalogue des vulnérabilités dont l’exploitation est connue – KEV, ou Known Exploited Vulnerabilities – et maintenu par l’agence américaine de la cybersécurité et des infrastructures (CISA) s’inscrit dans la même logique. 

Le CERT Coordination Center (CERT-CC) est allé plus loin avec le SSVC, ou Stakeholder-Specific Vulnerability Categorization. Il est décrit comme « un système permettant de hiérarchiser les actions lors de la gestion des vulnérabilités » et « vise à éviter les solutions uniques en faveur d’un système modulaire de prise de décision avec des parties clairement définies et testées, que les gestionnaires de la vulnérabilité peuvent sélectionner et utiliser en fonction de leur contexte ».

Hiérarchiser les actions

En pratique, le SSVC permet de construire un arbre de décision avec 4 résultats possibles : reporter l’application des correctifs, la programmer, y procéder hors cycle habituel de déploiement, ou encore la mettre en œuvre immédiatement. 

La prise de décision s’appuie sur quelques critères clés relatifs à l’exploitation de la vulnérabilité, l’exposition de l’organisation à celle-ci, l’utilité de l’exploitation pour un attaquant, et l’impact potentiel d’une exploitation réussie. 

Les équipes du CERT-IST en ont dérivé un arbre de décision simplifié, présenté en décembre 2022. En substance, si une vulnérabilité concerne un système exposé sur Internet et qu’elle est référencée dans le catalogue KEV, il convient d’agir immédiatement, soit pour déployer le correctif, soit pour mettre en œuvre les mesures d’atténuation connues. Et cela vaut également pour une vulnérabilité présentant le même contexte d’exposition, mais absente du catalogue KEV alors qu’un démonstrateur d’exploitation existe. 

En l’absence de possibilité d’exploitation publiquement connue, si le système est exposé sur Internet – ou à valeur élevée pour l’organisation – et que la vulnérabilité affiche un score CVSS supérieur à 9, il convient d’appliquer le correctif sans suivre le cycle nominal de déploiement des patchs.