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 !