L’objectif de ce dossier est de vous donner les pistes permettant d’améliorer cette pratique au sein de votre organisation.

Définition de la vulnérabilité

Comme souvent dans le monde de la Cybersécurité, il existe plusieurs définitions de la notion de vulnérabilité.

Selon la norme ISO 27005, une vulnérabilité est une « faille dans un actif ou dans une mesure de sécurité qui peut être exploitée par une menace » – Source : https://tinyurl.com/2s4bs8ju

Selon le NIST il s’agit d’une « faiblesse d’un système d’information, des procédures de sécurité du système, des contrôles internes ou de la mise en œuvre qui pourrait être exploitée ou déclenchée par une source de menace. » – Source : https://tinyurl.com/2p9ascze

Dans le cadre de cet article, je tenterai de donner une définition plus pragmatique pour le défenseur Cyber : « Toute CVE (Common Vulnerabilities and Exposures) non patchée ou mauvaise configuration permettant à un attaquant d’exécuter un chemin d’attaque afin d’exercer une action malicieuse au sein du système d’information ».

En effet, je rappelle ici qu’il n’existe finalement que deux moyens « d’attaquer » un système, quel qu’il soit : exploiter une CVE non patchée ou exploiter une mauvaise configuration du dit système. Ceci est applicable à toutes les composantes du système d’information : un PC sous Windows, un firewall, un téléphone IP, un annuaire, un code, etc.

Dans la suite de cet article, nous traiterons des vulnérabilités de type CVE, à savoir les failles identifiables sur les systèmes sur lesquels nous pouvons appliquer un patch pour corriger la faille. Nous ne traiterons pas ici de la partie mauvaise configuration, qui nécessiterait une encyclopédie à elle toute seule !

Un besoin de normalisation dans la pratique

Depuis environ une vingtaine d’années, la pratique de gestion des vulnérabilités (Vulnerability Management) s’est répandue dans la plupart des organisations souhaitant prendre en compte le risque Cyber et protéger leurs actifs des attaques. Depuis cinq ans, l’explosion des attaques par Ransomware a remis dans la lumière cette activité, car elle représente le socle fondateur pour se protéger des Malwares en tout genre.

• Un travail de fond des analystes et des organismes

Il est notable de constater que la plupart des analystes du domaine IT se sont emparés du sujet en proposant différents modèles permettant de formaliser la démarche en entreprise, par exemple le Gartner a publié une mise à jour de son « Vulnerability Management Guidance Framework » et a créé une série de documents décrivant la pratique, extrêmement intéressants à lire et à appliquer.

De son côté, l’OWASP publie et maintient à jour un guide de bonnes pratiques accessible sur Github : https://tinyurl.com/4up2cchu en se concentrant sur trois étapes essentielles du cycle : détection, reporting et remédiation. Ce modèle a l’avantage d’être très pragmatique et permet d’aller à l’essentiel, il est approprié pour les organisations peu matures sur le sujet.

Vous comprenez donc qu’il existe une multitude de modèles, accompagnés de leur lot d’avantages et d’inconvénients. La pratique a beau être ancienne, elle a toujours besoin de normalisation et d’évolution. La raison principale est que beaucoup de praticiens tentent d’appliquer les diverses méthodologies de gestion des risques pour modéliser leur pratique de gestion des vulnérabilités.

• Gestion des risques VS Gestion des vulnérabilités

Il est important à ce stade d’expliquer quelques termes et de dissocier la gestion des risques et la gestion des vulnérabilités. Il est en effet frappant de constater deux situations extrêmement courantes :

• Beaucoup d’organisations souhaitent appliquer des méthodologies de gestion des risques à la gestion des vulnérabilités – cela peut paraitre naturel, et pour être honnête, c’est que j’ai tenté de faire également au début de ma carrière – néanmoins je considère maintenant que les pures méthodologies de gestion des risques sont difficilement transposables pour gérer efficacement les vulnérabilités.
• Il existe une multitude de termes employés, parfois à tort, dans de nombreux modèles et documents (même dans les documents officiels des organismes de normalisation !) – certains termes sont considérés par certains comme interchangeables, d’autres praticiens tentent d’utiliser les termes dans un seul contexte précis essayant d’éviter la confusion – il est donc extrêmement compliqué de s’orienter dans la jungle des différents acronymes et documents, surtout lorsque l’on tente de les comparer.

Les éléments suivants sont basés sur ma propre interprétation, je ne considère pas qu’il s’agisse d’une vérité gravée dans le marbre – il s’agit plutôt du fruit de mon expérience, elle-même basée sur de la concaténation de dizaines de documents et sur l’observation de la pratique dans diverses organisations.

Voici un résumé des termes utilisés dans le cadre de la pratique de gestion des risques :

Pour le coup, la plupart des ressources documentant le sujet utilisent à priori les mêmes termes, la raison est simple, la pratique de gestion des risques existe depuis plusieurs millénaires (au sens propre) et les praticiens ont eu le temps de s’accorder sur les termes à employer et sur leurs définitions.

Voici les termes que j’utilise dans le cadre de la gestion des vulnérabilités :

Le diable se cachant dans les détails, une nouvelle variable est apparue dans la formule, la Sévérité. Pour faire simple, chaque CVE possède un score de sévérité intrinsèque, que l’on peut évaluer, l’idée est ici d’intégrer cette variable dans le calcul du risque lié à une vulnérabilité de type CVE. Mais comme nous le verrons plus loin dans cet article, la « chose » est un peu plus compliquée que cela… De plus certains praticiens remplacent le produit Probabilité par Sévérité par le concept de Criticité. Je dois bien avouer que je suis quelque peu réticent à utiliser ce terme – autant le concept de Sévérité me parait pertinent à intégrer dans le calcul, autant la notion de Criticité est pour le coup utilisée de différentes manières selon les usages, je préfère donc ne pas y faire référence afin de gagner en cohérence.

Retenez finalement que si vous tentez de comparer la littérature de gestion des risques à celle traitant des vulnérabilités, vous rencontrerez de grandes difficultés à relier les termes utilisés dans les deux pratiques, simplement parce que leur sens profond est interprété différemment par les praticiens de ces deux disciplines.

Mesure de la sévérité d’une CVE : CVSS

Les CVEs sont donc des vulnérabilités présentes sur les systèmes, elles sont référencées selon une codification, pour faire simple chaque CVE possède un numéro unique qui lui est attribué lors de sa découverte (c’est un peu plus compliqué que cela, mais restons simples). Voici un exemple avec la CVE CVE-2022-22321 :

Dans cet exemple, la CVE a été publiée le 03/01/2022, c’est IBM Corporation qui a fourni les informations et son score est de 5.5 selon CVSS 3.1.

La base de données des CVEs se nomme la NVD (National Vulnerability Database), elle est gérée et maintenue par un organisme gouvernemental Américain nommé NIST (National Institute of Standards and Technology) et elle est accessible en ligne ici : https://nvd.nist.gov/

Pointons ici du doigt un paradoxe intéressant : alors que la problématique de gestion et de normalisation des CVEs est un enjeu mondial, l’organisme responsable du maintien de la base de données de référence est de fait réalisé par un organisme financé par le gouvernement Américain. Pourtant, « tout le monde » utilise cette base de données et la considère comme un « standard de fait ».

Afin de catégoriser la Sévérité d’une CVE, le NIST utilise la notation CVSS (Common Vulnerability Scoring System), la dernière version de ce modèle de catégorisation étant la 3.1. En effet, comme l’indique l’organisme FIRST (Forum of Incident Response and Security Teams) responsable du maintien de la documentation CVSS, le score CVSS mesure une sévérité et non pas un risque :

Ce point est très important, le score CVSS ne mesure que la sévérité, pas la probabilité, pas l’impact et encore moins le risque. Néanmoins, comme nous le découvrirons plus loin dans cet article, le score CVSS peut fournir des recommandations pour mesurer les autres attributs, permettant finalement de se rapprocher d’une méthode classique d’évaluation du risque.

Le score CVSS attribué à une CVE s’étend sur une échelle de 0 à 10, plus le nombre est élevé, plus la sévérité est importante. Il est admis que si le score CVSS est supérieur à 7, alors la CVE est considérée comme critique, et doit donc par projection être patchée immédiatement. Comme nous le verrons plus loin dans cet article, le score CVSS a le mérite de fournir un cadre normatif mais ne permet qu’une approximation pour décider de la priorité des actions dans le cadre de la remédiation.

Pour information, le site cvedetails.com fournit des informations intéressantes concernant la répartition des scores CVSS sur l’ensemble des CVEs connues, soit au jour du 08/09/2022, 184 286 CVEs référencées !

Structure du score CVSS

Comme indiqué précédemment, le score CVSS mesure la sévérité d’une CVE, dans l’objectif de prioriser les actions de remédiation. Mais il faut bien comprendre que le score CVSS global est en fait la combinaison de trois scores différents :

• Le CVSS Base Score

Pour faire simple, il s’agit d’une caractérisation de la CVE elle-même, sans tenir compte de l’usage réel de cette CVE par les groupes d’attaquants ou de l’impact de cette CVE au sein de l’organisation. Les puristes souligneront qu’une partie du Base Score prend en compte l’impact, ce qui est vrai, mais je veux ici rester simple. Le NIST fournit donc des attributs liés à la CVE, et surtout les valeurs qui vont avec.

• Le CVSS Temporal Score

Cette partie du Score Global prend en compte la menace réelle sous le prisme de l’exploitabilité de la CVE. Par exemple, est ce que les groupes d’attaquants utilisent réellement cette CVE, existe-t-il une preuve de l’usage de cette CVE, un code permettant effectivement d’utiliser cette CVE a-t-il été publié sur Github, etc. Il est primordial de comprendre que le NIST définit les attributs importants à suivre, mais ne fournit pas les valeurs associées, ce qui est normal puisque ces valeurs ne peuvent être fournies que par des flux de CTI (Cyber Threat Intelligence) complémentaires.

• Le CVSS Environmental Score

Il s’agit ici de prendre en compte le contexte de l’organisation afin de pondérer la menace réelle : Quels sont les critères de sécurité de l’organisation, quel est l’impact potentiel de la CVE en termes de confidentialité, intégrité et disponibilité, etc. A nouveau, le NIST définit les attributs importants à suivre, mais ne fournit pas les valeurs associées, l’organisation devra par exemple réaliser une étude de risque pour alimenter ces attributs.

Composantes du score CVSS

Pour comprendre comment le score global évolue en fonction des différentes valeurs d’attribut, le NIST propose une calculatrice en ligne accessible ici : https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Cet outil est très utile aux débutants afin de comprendre la structure et les équations permettant le calcul du score CVSS.

La menace liée aux CVEs est grandissante

Lorsque l’on consulte les données existantes liées aux CVEs, deux éléments sautent aux yeux immédiatement :

• Chaque année, le nombre de CVEs découvertes augmente

Je ne parle pas ici du nombre cumulé de CVEs qui bien sûr augmente mécaniquement chaque année, mais du nombre de CVEs que les chercheurs découvrent année après année : 4653 CVEs découvertes en 2010, 7939 CVEs découvertes en 2014, 18325 CVEs découvertes en 2020, etc.

• Le nombre représentant les CVEs cumulés ne suit pas une droite mais une fonction exponentielle

De plus les vulnérabilités les plus anciennes sont toujours les plus exploitées, il y a deux ans, plus de 80% des cyberattaques recensées utilisaient une vulnérabilité publiée avant 2017 et plus de 20% de ces attaques exploitaient même une vulnérabilité connue depuis plus de 7 ans.

Nombres des CVEs cumulées au fil des ans

A la lecture de ces indicateurs, il apparait donc évident que les organisations voient la charge de travail liée à la gestion des vulnérabilités exploser et que seule la priorisation de la remédiation peut leur permettre de gérer cette situation. Historiquement, elles s’appuient sur CVSS pour définir les priorités, malheureusement, ceci n’est plus possible aujourd’hui pour les raisons que nous allons expliquer dans le prochain chapitre.

Les limites de CVSS

Si je devais me rappeler mes cours de mathématiques de l’université, je dirais que CVSS est nécessaire mais non suffisant. La pratique nous enseigne que CVSS possède de nombreux avantages : attributs normalisés, possibilités d’intégrer des concepts liés à la menace réelle et à l’organisation si on possède les sources de données adéquates, etc. Néanmoins la grande limitation de CVSS provient de son incapacité réelle à aider les organisations à la priorisation de la remédiation, c’est-à-dire définir quels sont les systèmes et CVEs à patcher en priorité pour éviter qu’une attaque ne survienne. Nous allons utiliser deux exemples pour illustrer ce fait.

• Il existe trop de CVEs avec un score Critique via CVSS

La notation CVSS existe depuis une vingtaine d’années, au début de l’utilisation de cette notation l’ensemble des scores attribués aux CVEs découvertes chaque année était équilibré, au sens où il y avait une répartition des scores plus ou moins équivalente sur l’échelle allant de 0 à 10 – Globalement, il y avait donc autant de CVEs avec un score de 4.5 que de CVEs avec un score de 8. Depuis une petite dizaine d’années, un déséquilibre s’est progressivement créé sur la répartition des scores – quand on consulte les scores des trois dernières années, on se rend compte que 2/3 des scores sont supérieurs à 6.5. Cette accélération vers des scores élevés nous amène à la situation suivante : si l’on fait la moyenne de tous les scores CVSS attribués depuis vingt ans, 1/3 des scores sont supérieurs à 7 et sont donc considérés comme critiques !

Voici deux graphiques illustrant parfaitement cette tendance de surreprésentation des scores élevés sur les deux dernières années :

Source: https://theoryof.predictable.software/articles/a-closer-look-at-cvss-scores/

Conclusion : Du fait de la surreprésentation des scores élevés, il n’est plus possible d’utiliser CVSS pour assurer la priorisation de la remédiation.

• Certains attributs CVSS possèdent un poids trop important dans l’algorithme

Lorsque l’on étudie l’algorithme de calcul du score CVSS afin d’appréhender la logique de notation, il apparait que certains attributs possèdent un poids surélevé dans le résultat du calcul. Par exemple, l’attribut Scope représente d’une certaine façon l’étendue de la vulnérabilité, si le Scope possède la valeur « Changed » cela signifie que la vulnérabilité peut impacter le système sur l’ensemble de ses sous-composants, si la valeur est égale à « Unchanged » les composants affectés sont limités au périmètre strict de la CVE. Bien évidemment, il s’agit d’un critère important pour évaluer le score CVSS que l’on attribue à une CVE donnée, mais lorsque nous regardons en détail il s’avère que la valeur « Changed » de l’attribut Scope est très largement surreprésentée dans les scores CVSS supérieurs à 7, donc considérés comme critiques. Le graphique suivant illustre la répartition des valeurs de l’attribut Scope en fonction du score global CVSS :

Source: https://theoryof.predictable.software/articles/a-closer-look-at-cvss-scores/

Conclusion : L’algorithme de calcul du score CVSS est déséquilibré et ne pondère pas efficacement les valeurs des différents attributs.

Stratégie pour une priorisation efficace

Comme vous l’avez compris, l’enjeu majeur du traitement des vulnérabilités réside dans la priorisation de la remédiation. Les équipes de production ne peuvent pas patcher l’ensemble des CVEs dont le score CVSS est supérieur à 7, surtout que les nouvelles CVEs découvertes sont en moyenne utilisées par les attaquants 48 heures après leur publication.

• Première piste : utiliser les attributs CVSS du Temporal Score et de l’Environmental Score

Comme indiqué précédemment, le NIST fournit les valeurs accompagnant les attributs du Base Score mais ne fournit pas les valeurs pour le Temporal Score et l’Environmental Score – Pour ces deux derniers scores le NIST ne fournit que la liste des attributs importants à considérer dans le score global.

L’organisation devra donc s’abonner à des flux de CTI pour renseigner les valeurs reliées à la menace réelle (Temporal). Afin de qualifier l’impact réel de la menace dans le contexte de l’organisation (Environmental), elle devra ingérer les données provenant d’une CMDB (Configuration Management DataBase) ainsi que les données provenant d’une étude de risque.

Il est clair que sans les composantes Temporal et Environmental le score CVSS est difficilement exploitable pour qualifier le risque.

• Deuxième piste : utiliser un algorithme complémentaire

Nous avons décrit plus haut les limites de l’algorithme CVSS, certaines organisations complètent le score CVSS par des algorithmes complémentaires permettant de qualifier le risque et non pas simplement la sévérité d’une CVE.

Parmi les algorithmes complémentaires, nous pouvons citer le SPR (Security Posture Rating) proposé par la société Vulcan mais celui-ci ne permet d’alimenter le score que via les valeurs présentes dans une CMDB et donc compléter les informations liées à l’impact (Environmental) – Il existe également le TRS (True Risk Score) développé par la société Hackuity qui a l’avantage d’intégrer les valeurs liées à la menace via des flux de CTI (Temporal) ainsi que les valeurs provenant de CMDBs et d’études de risques afin de qualifier l’impact réel (Environmental).

De plus, le NIST travaille activement sur une nouvelle version de CVSS, la version 4.0 – Cette nouvelle version permettra une mise à jour de l’algorithme de calcul mais ne fournira pas les valeurs associées à la menace ou à l’impact.

• Troisième piste : renforcer l’automatisation

Classiquement, la pratique de gestion des vulnérabilités est une activité hautement manuelle. En effet, il est très complexe d’automatiser le déploiement de patchs sur des serveurs de production, l’impact potentiel d’un patch doit être vérifié manuellement pour assurer la continuité de service des applications importantes pour le business.

Le volume de CVEs à patcher ne cessant d’augmenter, il devient indispensable de relier les informations collectées par les scanners de vulnérabilités avec les outils de gestion de tickets (ITSM) et de permettre ainsi un échange de données bidirectionnel entre ces deux outillages. En clair, les scanners de vulnérabilités doivent alimenter la création de tickets décrivant les patchs à déployer en priorité, après application du patch le système de gestion de tickets doit pouvoir renvoyer l’information dans la base de données décrivant le stock de vulnérabilités pour indiquer que le déploiement du patch a été réalisé.

Ce lien structurant nécessite généralement un développement spécifique ou l’implémentation d’un outil dédié.

• Quatrième piste : améliorer la coordination entre les équipes

Historiquement, un minimum de deux équipes différentes sont parties prenantes du cycle de gestion des vulnérabilités. Généralement les scanners de vulnérabilités sont gérés par les équipes sécurité du RSSI, de manière à obtenir une vue claire du stock de CVEs de l’organisation. Ensuite les équipes sécurité créent des tickets dans le système ITSM, ils sont attribués aux équipes de production. Ce sont classiquement les équipes de production qui déploient les patchs sur les systèmes car celles-ci maitrisent parfaitement les différentes machines présentes dans l’organisation et sont responsables du maintien des bonnes conditions opérationnelles.

Il devient indispensable de casser les silos entre ces deux équipes et d’utiliser les outils et processus permettant d’améliorer la coordination entre tiers. Cette évolution n’est pas le seul fait d’outils supplémentaires mais nécessite une réorganisation des méthodes de travail.

• Cinquième piste : intégrer les informations liées aux Pentest et au Bug Bounty

Lorsque l’on évoque la gestion des vulnérabilités on pense immédiatement aux informations présentes dans les résultats des scanners de vulnérabilités. Evidemment, il s’agit d’un élément primordial, de plus, les données présentes dans ces outils ont l’avantage d’être structurées (du moins au sein d’un même éditeur !). Mais il existe un autre référentiel utile décrivant les vulnérabilités et leur exploitation réelle, il s’agit des rapports de Pentest et de Bug Bounty.

De nombreuses organisations commencent à alimenter leur cycle avec les informations présentes dans ces rapports, permettant ainsi de mieux qualifier le risque réel. Le problème est que ces rapports ne sont pas tous structurés de la même manière et demandent à être adaptés pour une gestion efficace au sein du référentiel.

Néanmoins, si l’effort de normalisation est effectué, ceci représente une avancée majeure dans le traitement des vulnérabilités.

Les ressources complémentaires pour bien appréhender la pratique

Voici une liste de ressources complémentaires qui vous permettront d’explorer en profondeur la pratique de gestion des vulnérabilités.

• Mon précédent article sur ITPro traitant de la gestion de la surface d’attaque : https://tinyurl.com/2p9ea9j3
• Le site de la National Vulnerability Database : https://nvd.nist.gov/
• La calculatrice en ligne du score CVSS : https://tinyurl.com/2bb62hxm
• Le document du FIRST décrivant les spécifications officielles du score CVSS : https://www.first.org/cvss/v3.1/specification-document
• Le site CVE Details fournissant des statistiques sur les CVEs : https://www.cvedetails.com/

J’espère sincèrement que cet article vous aura éclairé sur la pratique de gestion des vulnérabilités et que vous avez pu trouver des pistes concrètes pour améliorer la gestion des risques au sein de votre organisation. Bien évidement votre réflexion ne doit pas s’arrêter à cet article, vous devrez chercher et comprendre par vous-même de nombreux concepts afin d’améliorer votre niveau de sécurité global.

N’hésitez pas à me suivre sur Linkedin ou à me contacter directement afin de poursuivre la conversation.

Sylvain Cortes – Microsoft MVP- Linkedin : https://www.linkedin.com/in/sylvaincortes/

sylvaincortes@hotmail.com