Le pilotage des vulnérabilités par le risque
L’attention particulière portée, ces jours-ci, au risque cyber montre bien que ce dernier fait partie intégrante des risques de l’entreprise. Cependant, la posture du risque cyber peut être sérieusement affectée par l’incapacité des organisations à réagir face au nombre croissant de vulnérabilités impactant les différentes composantes du système d’information. En effet, le dédoublement de vulnérabilités détectées ces dernières années et leur diversification, le manque d’information sur les assets (inventaire, cycle de vie) et la non-maitrise des ressources des processus de MCS (maintien en conditions de sécurité) constituent des challenges auxquels on doit répondre pour la mise en place d’un programme efficace de remédiation des vulnérabilités.
Gérer des vulnérabilités au quotidien
Avec la multiplication des outils de détection de vulnérabilités : scanneurs de vulnérabilités, SBOM (CISA-SBOM), EDR, CERT, … et la standardisation des échanges sur les vulnérabilités ; VEX (NTIA), une organisation de « bonne taille » peut facilement avoir des centaines de milliers voire des millions de vulnérabilités détectées dans ses environnements physiques, virtualisés ou conteneurisés et impactant des firmwares, des OS, des middlewares, des Bases de données, des applications…
L’expérience montre qu’il est impossible de tout remédier car tout simplement les ressources dont disposent l’entreprise ne sont pas illimitées. Naturellement, nous pensons à prioriser les vulnérabilités les plus urgentes à corriger. Cette priorisation, exprimée sous forme d’une politique de gestion de vulnérabilités, vise à réduire la surface d’exposition des assets les plus critiques aux menaces imminentes qui pourraient mettre en péril une partie ou la totalité du SI de l’entreprise.
Afin de prioriser le traitement des vulnérabilités les plus à risque, chaque organisation implémente sa propre politique de gestion de vulnérabilité qui contient une section dédiée à la quantification du risque des vulnérabilités et les délais de remédiation associés à chaque niveau de risque. Cette politique évoluera dans le temps en fonction de la maturité de l’organisation dans la maitrise du risque cyber. Dans un premier temps, elle peut être « basique » mesurant le risque sur la seule métrique du CVSS (First CVSS) comme le montre le tableau ci-dessous :
En plus de cette grille, il est recommandé de définir un niveau de « crise » et des modalités de déclanchement et de sortie de crise. Ce niveau, qui traite d’une menace immédiate exploitant une vulnérabilité connue, est généralement atteint suite à un incident de sécurité grave ou suite à une alerte d’un organisme de surveillance des menaces cyber tel que le CERT (voir réf).
Cette approche statique peut s’avérer inefficace quand le nombre de vulnérabilités est trop important ou face à une vulnérabilité complexe à remédier telle que la log4j (voir réf) rendant leur traitement un cauchemar pour les équipes en charge du suivi et de remédiation. Par exemple, un responsable d’une application se voit notifier d’une manière continue d’assignations de vulnérabilités pour lesquelles il doit préparer des plans d’actions et communiquer des dates de remédiation (ou d’acceptation de risque). Il ne peut tout simplement pas suivre face à l’ampleur du travail à consentir. Cela crée de la frustration et des tensions entre les intervenants et peut même s’avérer dommageable à la crédibilité de l’ensemble de la chaine de gestion de vulnérabilité (détection, communication et procédures de remédiation).
Pour construire un programme efficient de remédiation de vulnérabilités, il est primordial d’apporter des réponses claires aux questions suivantes :
- Quelle est la meilleure formule qui me permet de mesurer le risque réel de mes vulnérabilités ?
- Mes assets critiques sont-ils clairement identifiés ?
- Quelles sont les ressources mises à disposition pour traiter efficacement mes vulnérabilités dans des délais raisonnables (outillage, processus, budget et capacité à faire)?
- Comment contrôler et mesurer les performances de mon programme de gestion de vulnérabilité ?
Le pilotage des vulnérabilités par le risque
La grille présentée précédemment est basée sur la seule métrique CVSS qui, en soit, ne donne pas d’indication sur l’exploitabilité de la vulnérabilité sachant qu’en réalité moins de 5% de vulnérabilités sont vraiment exploitables (CISA-CATALOG). D’autre part, il n’existe aucune référence à la criticité de l’asset (impact business, exposition, conformité, …).
Donc, deux ingrédients doivent être impérativement intégrés dans la formule de calcul de priorisation des vulnérabilités ; l’exploitabilité de la vulnérabilité et la criticité de l’asset.
Mais comment faire pour déterminer l’exploitabilité d’une vulnérabilité ?
La première solution consiste à utiliser les métriques offertes par les outils tels que Tenable, Qualys, Rapid7 et Tanium , … qui disposent d’une vue holistique sur l’écosystème des vulnérabilités et leur traitement. Dans cette section, nous donnons un aperçu sur ces métriques et comment les utiliser pour définir une procédure de priorisation du traitement des vulnérabilité. Il est préconisé d’y adjoindre une analyse de risque pour étayer le choix des métriques pour chaque niveau de risque et les délais de remédiation qui s’y réfèrent.
- VPR de Tenable :
Tenable.sc fournit un Vulnerability Priority Rating (VPR) pour la plupart des vulnérabilités. Le VPR est une métrique dynamique calculée à partir du score CVSS de la vulnérabilité et des données collectées des menaces encours. Les valeurs VPR vont de 0,1 à 10 une valeur plus élevée représentant une probabilité d’exploitation plus élevée. Les mesures sur lesquelles se base le calcul de la VRP sont illustrées dans le tableau suivant :
- Vulnerability Age : Nombre de jours écoulés depuis la publication de la vulnérabilité par la base de données nationale sur les vulnérabilités (NVD)
- CVSSv3 Impact Score : Score d’impact CVSSv3 fourni par NVD pour la vulnérabilité. Si le NVD n’a pas fourni de score, Tenable.sc affiche un score prédit par Tenable
- Exploit Code Maturity : La maturité relative d’un exploit possible pour la vulnérabilité basée sur l’existence, la sophistication et la prévalence de l’intelligence d’exploitation provenant de sources internes et externes (par exemple, Reversinglabs, Exploit-db, Metasploit, etc.). Les valeurs possibles (High, Functional, PoCou Unproven) sont parallèles aux catégories CVSS Exploit Code Maturity
- Product Coverage : Le nombre relatif de produits uniques touchés par la vulnérabilité : Low, Medium, Highou Very High
- Threat Sources : Une liste de toutes les sources (par exemple, les canaux de médias sociaux, le Web sombre, etc.) où des événements de menace liés à cette vulnérabilité se sont produits. Si le système n’a pas observé d’événement de menace connexe au cours des 28 derniers jours, le système affiche : No recorded events
- Threat Intensity : L’intensité relative basée sur le nombre et la fréquence des événements de menace récemment observés liés à cette vulnérabilité :Very Low, Low, Medium, Highou Very High
- Threat Recency : Nombre de jours (0-180) depuis qu’un événement de menace s’est produit pour la vulnérabilité
- TruRisk de Qualys :
TruRisk est disponibe dans la version VMDR 2.0 ( Vulnerability Management. Le calcul du score TruRisk implique divers paramètres tels que, la criticité de l’asset (ACS), le score de détection Qualys (QDS) et le score de vulnérabilité Qualys (QVS). Ce système de scoring a le mérite d’être plus transparent que le VPR de Tenable. Cependant, il nécessite la production d’une mesure contributive (allant de 1 à 5) qui reflète la criticité de l’asset (ACS). Cette mesure peut être automatisée par un système de TAGS dynamique déjà présent dans Qualys. Le score de détection Qualys (QDS) et le Qualys Vulnerability Score (QVS) sont des scores attribués par Qualys pour une vulnérabilité. Ils se bases sur plusieurs facteurs associés à la CVE tels que CVSS et d’autres indicateurs externes sur les menaces tels que l’exploitation active de la vulnérabilité, la maturité du code d’exploitation, la qualification CISA et bien d’autres. Cependant, Qualys propose différents contrôles d’atténuation (CID) qui s’appliquent à ces scores en vue d’ajuster le niveau de risque. Ce réajustement se base sur des informations complémentaires venant d’autres contrôles tels que les scans de conformités basés sur les CIS benchmarks par exemple.
La formule suivante est utilisée pour calculer le score TruRisk de qualys :
- RRS de Rapid7 :
Rapid7 InsighVM produit un scoring Risk Rating Score assez opaque en se basant sur les métriques CVSS, sur les tags de criticité des assets (qu’il faudra renseigner) et un processus interne de surveillance des menaces liées aux vulnérabilités affichées « Threat Feeds ». le risque est mesuré sur une échelle de 1 à 1000.
- Risk overview de TANIUM:
Tanium utilise une approche globale pour mesurer le risque cyber. La vulnérabilité est l’une des mesures utilisées dans la formule de calcul du score final d’un asset. Malheureusement, là encore, Tanium fournit peu de détail sur la quantification du risque lié aux conditions d’exploitabilité de la vulnérabilité. Comme l’est dans les autres métriques, la fourchette possible pour un score de risque est de 1 à 1000.
La formule suivante est utilisée pour calculer le score de risque pour chaque asset:
(Vecteurs de risque x Criticité de l’asset) x (100 % – Contrôle compensatoire %) = Score du point final
Où les vecteurs de risque sont :
- Vulnérabilité du système
- Conformité du système
- Accès administratif
- Identification par mot de passe
- Certificats expirés
- SSL/TLS non sécurisé
L’alternative à l’utilisation des métriques offertes par les outils de détection pour mesurer le niveau de risque et la criticité des vulnérabilités est de construire son propre système de scoring. A moins d’être un acteur majeur dans la cybersécurité, cette approche est couteuse en termes de ressources humaines et outillage de surveillance.
Néanmoins, il est recommandé de challenger les métriques des outils de détection avec d’autres sources telles que les CERT (CERT-US, CERT-FR, …) et les publications éditeurs ou de threat-intelligence tierces.
