Nous avons récemment ouvert les contributions à ce blog aux start-ups accélérées par notre dispositif Shake’Up. Hackuity repense la gestion des vulnérabilitiés grace à une platforme qui collecte, normalise et orchestre les pratiques d’évaluation de la sécurité automatisées et manuelles et les enrichit avec des sources de données de Cyber Threat Intelligence, des éléments de contexte technique et les impacts business. Hackuity permet notamment de valoriser l’arsenal de détection des vulnérabilités existant, de prioriser les vulnérabilités les plus importantes, de gagner du temps sur les tâches à faible valeur ajoutée et de réduire les coûts de remédiation, d’accéder à une vision exhaustive et continue de la posture de sécurité de l’entreprise et de répondre aux obligations de conformité.
Après avoir vu dans un premier article l’état de la menace et les problématiques actuelles liées à la gestion des vulnérabilités, nous verrons dans ce second article les nouvelles approches à prendre en compte pour mieux gérer les vulnérabilités, notamment via la priorisation de la remédiation proposée par Hackuity.
L’avènement du « Risk-Based Vulnerability Management » (RBVM)
La gestion des vulnérabilités basée sur le risque, « Risk Based Vulnerability Management » (RBVM) est une approche qui traite chaque vulnérabilité en fonction du risque qu’elle représente pour chaque entreprise.
Dans ce contexte, la formule classique de calcul d’un risque s’applique :
La première partie de la formule, vulnérabilité × menace, peut également être considérée comme une probabilité. Cette probabilité décrit les chances qu’une vulnérabilité donnée soit découverte et utilisée par un acteur de la menace dans le contexte technique spécifique de l’organisation concernée. La dernière partie de la formule décrit les conséquences, ou l’impact, d’une attaque réussie par un acteur de la menace dans le contexte métier de l’entreprise
C’est en synthèse l’approche retenue par CVSS, une norme développée par le FIRST (Forum of Incident Response and Security Teams), initialement pour quantifier la gravité technique d’une vulnérabilité. Au travers de 3 métriques (base, temporelle, environnementale), l’ensemble du score CVSS (aujourd’hui dans sa version 3.1) est censé refléter le risqué réel qui pèse sur chaque vulnérabilité, dans le contexte de chaque entreprise.
Source: FIRST (https://www.first.org/cvss/specification-document)
L’objectif n’étant cependant pas ici de décrire CVSS, nous supposons que le lecteur est familier avec ce concept. Le score CVSS comporte de nombreux avantages, parmi les principaux :
- Le seul standard du marché disponible pour mesurer la criticité d’une vulnérabilité,
- Un algorithme détaillé et transparent,
- Un scoring largement adopté par l’industrie,
- Des bases de référence mondiales (notamment pour qualifier la criticité des CVE).
Cependant, il comporte de nombreuses limitations, dont on peut lister les principales ici :
- Sa faible granularité; chacune des métriques est composée de valeurs catégorielles avec des valeurs prédéterminées (ex : faible, moyenne, élevé) ce qui limite ses capacités de discrimination.
- Sa vocation à qualifier unitairement les vulnérabilités : il est ainsi impossible d’évaluer la criticité d’un scénario complet d’attaque avec CVSS. Certaines cyberattaques vont par exemple exploiter plusieurs vulnérabilités de criticité modérée pour arriver à compromettre un périmètre entier. Cependant, l’évaluation CVSS ne portera que sur chacune des failles prise de façon indépendante ; il sera nécessaire pour l’auditeur de présenter le scénario dans sa globalité et de mettre en lumière le risque final, sans qu’il ne puisse s’appuyer sur un score CVSS, celui-ci n’ayant pas pour vocation d’être agrégé.
- Son caractère arbitraire: les poids et l’algorithme semblent parfois être composés de chiffres arbitraires rendant l’interprétation de ces valeurs complexe. Finalement, on constate une marge d’erreur parfois significative dans la quantification CVSS d’une même vulnérabilité par deux professionnels.
D’autre-part, faut-il le rappeler (?) les scores CVSS publics, comme ceux référencés dans le NVD, ne sont que des scores de base. Ils représentent la gravité intrinsèque d’une vulnérabilité, mais ne reflètent pas le risque que cette vulnérabilité représente pour l’entreprise. En d’autres termes, ils répondent à la question « Est-ce dangereux ? », mais pas à la question « Est-ce dangereux maintenant pour mon entreprise » ?
Une gestion efficace des vulnérabilités doit tenir compte non seulement du score de base, mais aussi des facteurs temporels et environnementaux. Le FIRST fournit le cadre, mais le NIST ne peut pas calculer le score CVSS pour l’entreprise, car il nécessite une connaissance de la criticité des actifs, l’identification des contrôles en place, l’exploitabilité de la vulnérabilité dans ce contexte précis ou l’intensité de la menace réelle et actuelle.
Sur le terrain, pourtant, on constate que près de 45% des entreprises interrogées – toutes tailles confondues – n’utilisent pour seul métrique de quantification de la criticité des vulnérabilités que le score CVSS de base.
Au-delà de la pertinence de cette approche, l’utilisation de cette métrique unique ne résout pas la problématique majeure de l’industrie qui reste le volume de vulnérabilités à traiter.
Sur les 123 454 vulnérabilités (CVE) recensées au 15/01/2020, plus de 16 000 avaient un score CVSS de base (V2.0) jugé critique (soit plus de 13% du total).
Au-delà de CVSS ?
L’objectif de la priorisation est donc de réduire le stock de vulnérabilités à traiter en priorité en discriminant les plus critiques afin de permettre de concentrer les équipes et moyens de remédiation sur les vulnérabilités qui comptent réellement.
D’autre part, il ne fait aucun doute que l’avalanche quotidienne de nouvelles vulnérabilités remontées par l’arsenal de détection ne peut plus être gérée manuellement. Il est totalement irréaliste d’examiner manuellement toutes les vulnérabilités identifiées, de les analyser et de les classer par ordre de priorité.
L’automatisation de la pratique doit permettre aux équipes de travailler plus efficacement, en réduisant les tâches et les processus manuels répétitifs et/ou à faible valeur ajoutée.
Pour répondre à ces besoins et aux limites de CVSS, les acteurs du RBVM introduisent :
- De nouvelles métriques (scores) de mesure du risque – propriétaires – qui viennent compléter, surcharger ou remplacer CVSS,
- L’automatisation des tâches d’analyses et de mesure, et notamment la corrélation avec des sources de menaces (CTI) pour qualifier en continu l’intensité de la menace associée à chaque vulnérabilité.
Plus généralement, l’approche RBVM prend en compte de nombreuses métriques d’évaluation pour établir un score basé sur le contexte et la menace. 4 grandes catégories de critères semblent faire consensus :
1/ La vulnérabilité ou les caractéristiques individuelles – intrinsèques – de la vulnérabilité elle-même.
Au travers de ces critères il s’agit de mesurer la gravité d’une vulnérabilité en prenant en compte des métriques qui sont constantes dans le temps et quels que soient les environnements, comme par exemple les privilèges requis pour exploiter la vulnérabilité ou encore son vecteur d’attaque (à distance, sur le même réseau local, avec un accès physique, etc.).
Pour cette catégorie, le score CVSS de base (généralement pris dans sa version 2.0 pour assurer l’antériorité) est un point de départ solide pour l’analyse de la criticité intrinsèque de la vulnérabilité. C’est d’ailleurs le score repris par la plupart des solutions du marché.
2/ Les menaces externes qui vont servir à quantifier l’intensité – actuelle – de la menace associée à chaque vulnérabilité.
Les métriques utilisées reflètent des caractéristiques qui peuvent changer au fil du temps mais pas d’un environnement technique à l’autre.
« La vulnérabilité est-elle associée à des sujets d’actualité sur les forums de discussion, le darknet et les réseaux sociaux ? Un mécanisme d’exploitation a-t-il été publié ou est-elle actuellement exploitée par un ransomware particulièrement virulent ? »
La disponibilité d’un « exploit » associé à une vulnérabilité est par exemple un facteur important repris par la plupart des de solutions de gestion des vulnérabilités par les risques. Selon une étude Tenable Research, 76% des vulnérabilités avec un score de base CVSS > 7 n’ont pas d’exploit disponible.
Source: (https://fr.tenable.com/research)
Cela signifie que des entreprises qui s’attacheraient à corriger toutes leurs vulnérabilités de criticité « Haute » ou « Critique » selon CVSS consacreraient plus des trois quarts de leur temps à combler des failles qui ne représentent au final que peu de risques. Pour une meilleure efficacité opérationnelle, il est donc opportun de concentrer les efforts de remédiation sur les vulnérabilités pour lesquelles un exploit a déjà été publié.
Mais c’est loin d’être le seul critère pertinent. En l’absence d’exploit connu, l’âge de la vulnérabilité pourra être pris en compte pour calculer sa probabilité d’exploitation, par une approche statistique, en fonction des occurrences d’exploitation mesurées. Certaines initiatives comme EPSS (Exploit Prediction Scoring System)[1] s’essayent même à prédire la « weaponization » des vulnérabilités.
Tout comme l’âge de la vulnérabilité, l’ancienneté de l’exploit est également un facteur qui va influer sur la probabilité d’exploitation. On relève par exemple que le taux d’exploitation d’une CVE explose au moment de la publication de l’exploit pour ensuite progressivement diminuer.
Plus généralement, l’intensité actualisée de la menace est un critère déterminant dans l’algorithme de priorisation. Au-delà d’approches statistiques, elle peut être quantifiée en monitorant des sources de CTI, les réseaux sociaux ou encore des publications diverses comme par exemple en quantifiant le nombre d’occurrences de ces vulnérabilités dans les discussions de forums cybercriminels.
On pourra ainsi déterminer qu’un nouveau malware particulièrement actif exploite une vulnérabilité et donc pondérer à la hausse sa criticité.
Beaucoup d’autres indicateurs peuvent être intégrés pour affiner la pertinence de la priorisation des vulnérabilités. La solution Hackuity prend notamment en compte plus de 10 critères en complément des métriques du standard CVSS pour calculer son « True Risk Score » :
Outre la pertinence du choix de ces critères et de l’algorithme de calcul lui-même, la nature et la qualité des sources de CTI monitorées pour renseigner en continu ces métriques représentent un enjeu important.
Parmi les sources utilisées, citons les nombreuses sources ouvertes (OSINT) sur les vulnérabilités et les menaces (NIST-NVD, Exploit-db, Metasploit, Vuldb, PacketStorm, OpenCVE, …) dont certaines consolidées au travers d’initiatives Open-source comme VIA4CVE (https://github.com/cve-search/VIA4CVE).
On compte aussi de très nombreux acteurs privés qui proposent des sources de CTI commerciales plus ou moins spécialisées dans l’intelligence sur les vulnérabilités.
3/ Le contexte technique ou les caractéristiques uniques de l’environnement dans lequel se trouve l’actif.
Il s’agit au travers de cette catégorie de mesurer la probabilité / difficulté d’exploitation d’une vulnérabilité dans le contexte spécifique de chaque organisation.
« L’actif est-il exposé sur l’Internet ou hébergé au fin-fond du Datacenter de l’entreprise ? Quelles sont les mesures techniques (protection, détection) qui le rendent plus ou moins vulnérable aux attaques ? »
Si certains acteurs se limitent à déterminer qu’un actif est exposé sur internet sur la base de son plan d’adressage IP, d’autres comme Hackuity vont chercher à mesurer la profondeur des arbres d’attaques nécessaires pour exploiter la vulnérabilité dans le SI de l’entreprise.
Ces caractéristiques sont par définition propres à chaque environnement. Il est donc nécessaire de disposer, prélever ou déterminer ces informations notamment en alimentant la formule de priorisation avec des données contextuelles liées aux actifs, par exemple des extraits de référentiels internes, lorsqu’ils existent.
4/ La criticité business de l’actif.
Il s’agit de mesurer les conséquences, ou l’impact, d’une attaque réussie par un acteur de la menace dans le contexte métier de l’entreprise.
« L’actif concerné par la vulnérabilité est-il critique pour l’organisation d’une manière ou d’une autre ? Héberge-t-il des informations sensibles ou nominatives ? Quels sont les impacts pour l’entreprise en termes financier, de réputation ou de conformité en cas d’exploitation de la vulnérabilité ? »
Tout autant que pour le contexte technique, ces caractéristiques sont spécifiques à chaque environnement. Il peut s’agir d’informations renseignées manuellement ou bien issues de résultats d’analyse de risque tels que des Business Impact Analyses.
Pour conclure sur le RVBM, quel que soit le degré d’automatisation apporté par la Solution, celle-ci ne prendra sa pleine mesure qu’avec l’apport d’éléments contextuels que l’outil ne peut deviner (impacts métier, environnement technique des actifs, organisation, processus, etc.).
Au-delà du RBVM, les technologies de VPT (Vulnerability Prioritization Technology)
Si les grands leaders du marché de la détection de vulnérabilités du marché ont aujourd’hui adopté une approche de gestion des vulnérabilités par les risques, ils n’ont pas adressé le principal problème associé à l’approche « best-of-breed » de la détection : les entreprises utilisent plusieurs outils et pratiques de détection pour assurer une couverture complète et efficace de leur périmètre.
Nombre moyen d’outils de détection selon la taille de l’entreprise / Hackuity – Panel de 93 entreprises
Comme évoqué précédemment, ce recours – nécessaire – à un arsenal hétérogène favorise une perception morcelée et non consolidée de la situation, ce qui limite les capacités de passage à l’échelle et, avec le volume des vulnérabilités croissant, entraine une explosion des coûts.
Pour répondre à ce problème, les acteurs du marché émergeant que le Gartner appelle VPT (« Vulnerability Prioritization Technology »), comme Hackuity, exploitent de manière agnostique les sources de vulnérabilité.
Ils collectent et centralisent les vulnérabilités issues de l’arsenal de détection de l’entreprise quel qu’il soit : multiples pratiques (test d’intrusion, bug-bounty, red team, etc.), éditeurs de solutions de détection des vulnérabilités (scans de vulnérabilités, SAST, DAST, IAST, SCA, etc. ) et sources de veille en vulnérabilités. Les principales caractéristiques des solutions de VPT sont décrites ci-après.
Schéma de principe de la solution Hackuity
Une vision exhaustive de l’état du stock de vulnérabilités
L’automatisation de la collecte des vulnérabilités permet aux équipes de la filière sécurité de disposer, parfois pour la première fois, d’une vision consolidée et centralisée du stock de vulnérabilités de l’entreprise, indépendamment des solutions ou pratiques de détections mises en œuvre.
Une opération capitale – et très rarement réalisée – est la conversion des formats propriétaires dans un format normalisé, qui va permettre par la suite de dé-dupliquer des clones d’une même vulnérabilité qui aurait été identifiée par plusieurs sources différentes (ex. une même injection SQL identifiée dans le cadre d’un test d’intrusion et lors d’un scan de vulnérabilités).
Ainsi, le méta-référentiel des vulnérabilités d’Hackuity est une base de connaissances multilingue qui fournit une description unifiée et normalisée de toutes les vulnérabilités, y compris les mesures correctives, les correctifs, les coûts de remédiation ou l’exploitabilité, sans perte d’informations remontées par la source d’origine.
L’établissement et l’enrichissement d’un inventaire des actifs
Sur le terrain, il n’existe que de rares exceptions d’entreprises qui disposent d’un référentiel de leurs actifs jugé complet ou au moins fiable (CMDB, ITAM, …). C’est d’ailleurs un problème endémique à la pratique et parfois le principal frein à la mise en place d’une politique de gestion des vulnérabilités efficient dans les entreprises. Afin de résoudre ce problème, certaines solutions intègrent dans leurs fonctionnement l’établissement dynamique et continu du référentiel des actifs de l’entreprise. Cette cartographie est établie par analyse et corrélation des données techniques collectées (ex. la stack logicielle installée sur un serveur, ses différents alias, etc.) et permet de disposer d’une base d’actifs continuellement maintenue à jour avec des données en provenance de multiples sources.
La criticité des actifs est également un élément clé dans le processus de mesure des risques liés aux vulnérabilités et qui compte pour près de 50% dans une approche de priorisation. Sans un inventaire précis des actifs et une évaluation de leur criticité dans l’environnement « business » de l’entreprise, il est impossible de calculer avec précision le risque réel associé à chaque vulnérabilité. Certains acteurs, tel qu’Hackuity, vont pallier l’absence ou à la non-complétude des analyses de risques en évaluant automatiquement la criticité des actifs en s’appuyant sur leurs propriétés techniques et opérationnelles (types et familles d’outils installés, densité des interconnexions, bases de données hébergées, etc.).
Au final, pour disposer d’informations consolidées sur les vulnérabilités ou les actifs de l’entreprise, plus besoin de maîtriser des dizaines d’outils ou de formats : le coût et la charge de travail liés à la gestion d’outils disparates sont considérablement réduits.
Le chainon manquant entre la détection et la remédiation des vulnérabilités
Enfin, le lien bidirectionnel avec les équipes en charge de la remédiation ou de la supervision sécurité permet de disposer d’une approche collaborative pour la gestion du stock de vulnérabilités.
En effet, si l’automatisation est devenue un levier indispensable à la gestion des vulnérabilités, il n’en reste pas moins que le facteur humain reste au cœur du processus.
Dans la plupart des entreprises, la gestion des vulnérabilités voit en effet intervenir 3 acteurs qui doivent travailler de concert :
- Les équipes sécurité en charge d’opérer les outils de détection et de piloter les plans de remédiation,
- Les responsables business qui vont arbitrer ou éclairer les plans de remédiation à l’aune des contraintes métier,
- Les opérationnels en charges de déployer les mesures correctives (patch management, configuration, développements, etc.)
L’efficience du processus ne se limite donc pas à l’automatisation du recueil des vulnérabilités. Dans la partie aval du processus (la gestion de la remédiation), des play-books permettent de mobiliser les ressources nécessaires à la mise en œuvre des correctifs : identification du porteur de la correction, création automatique de tickets d’incidents, génération de scripts pour les solutions Infrastructure as Code, etc.
En amont, le RSSI dispose enfin, et bien souvent pour la première fois, d’une perception en temps réel de l’avancée des plans de remédiation.
La solution de gestion des vulnérabilités est alors l’orchestrateur de l’écosystème visant à détecter, qualifier, corriger et suivre les vulnérabilités affectant l’entreprise.
Conçu comme un système ouvert, il permet également de nourrir les outils et processus tiers (SIEM, GRC, IR, Forensics, etc.) avec des données consolidées et structurées sur les vulnérabilités, actifs et menaces qui affectent l’entreprise.
Conclusion
Véritable pierre angulaire de la cybersécurité des entreprises, la gestion des vulnérabilités peut aujourd’hui (enfin) être synonyme d’une pratique scalable, efficace et pour laquelle il est possible de disposer d’indicateurs factuels traduisant les efforts déployés par les équipes sécurité et les équipes en charge de la remédiation.
Outre les retombées directes sur la posture sécurité de l’entreprise via la réduction de la fenêtre d’exploitation des vulnérabilités ou encore la mobilisation des experts sur des tâches à haute valeur ajoutée, l’intégration d’une solution d’orchestration de la gestion des vulnérabilités peut aussi se traduire par des retombées indirectes comme une meilleure connaissance du Système d’Information ou encore un engagement décuplé des équipes grâce à la quantification de l’impact de leurs actions sur la sécurité de l’entreprise.
