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 :

1. 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.
2. 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é.
3. 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 :

1. Les équipes sécurité en charge d’opérer les outils de détection et de piloter les plans de remédiation,
2. Les responsables business qui vont arbitrer ou éclairer les plans de remédiation à l’aune des contraintes métier,
3. 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.

[1] https://arxiv.org/pdf/1908.04856.pdf

Cet article Hackuity | Shake’Up – Le futur de la gestion des vulnérabilités: vers de nouvelles approches basées sur les risques et sur la priorisation (2/2) est apparu en premier sur RiskInsight.

De quoi parle-t-on ?

L’ISO 27005 définit une vulnérabilité comme « une faiblesse d’un actif ou d’un groupe d’actifs qui peut être exploitée par une ou plusieurs menaces, où un actif est tout ce qui a une valeur pour l’organisation ». Pour le SANS, la gestion des vulnérabilités est « le processus par lequel les vulnérabilités informatiques sont identifiées et les risques liés à ces vulnérabilités sont évalués. Cette évaluation conduit à la correction des vulnérabilités et à la suppression du risque ou à une acceptation formelle du risque ». Au fil du temps, la gestion des vulnérabilités est devenue une pratique fondamentale de la cybersécurité et les professionnels du métier s’accordent aujourd’hui unanimement pour dire que c’est un processus essentiel pour minimiser la surface d’attaque de l’entreprise.

Source: https://blogs.gartner.com/augusto-barros/2019/10/25/new-vulnerability-management-guidance-framework/

La gestion des vulnérabilités est ainsi désormais intégrée dans tous les grands référentiels, standards, régulations sectorielles, guides ou bonnes pratiques de sécurité (ISO, PCI-DSS, guide d’hygiène de l’ANSSI, GDPR, accords de Bâle, LPM, NIS, …) et est même réglementaire dans certains contextes. Toute bonne politique de sécurité d’entreprise y accorde d’ailleurs un chapitre significatif.  Un mal nécessaire pour beaucoup.

Vulnérabilités : état de la menace

Cependant, en 2019, selon une étude menée par le Ponemon Institute[1] « 60% des incident de sécurité étaient [encore] la conséquence de l’exploitation d’une vulnérabilité pourtant connue mais non encore corrigée par les entreprises ».

Pour illustrer l’ampleur actuelle du phénomène, considérons la grande menace cyber de 2020 et probablement de 2021 : les ransomwares. Bien que les ransomwares se propagent généralement par des actions initiées par l’utilisateur, comme cliquer sur un lien malveillant dans un spam ou visiter un site web compromis, une grande partie de ceux-ci exploitent également des vulnérabilités informatiques. Ainsi, si on analyse en détail le top-5 des ransomwares les plus virulents en 2020 selon intel471[2], on constate que leurs « kill-chain » exploitent toutes des vulnérabilités (CVE).

Source: Hackuity & National Vulnerability Database (https://nvd.nist.gov/)

Autre constat, il s’agit souvent de vulnérabilités déjà référencées par le NIST lors de l’apparition du ransomware, parfois même depuis plusieurs années, et dont les éditeurs proposaient un correctif ou une méthode de contournement. Une récente étude de CheckPoint[3] vient confirmer que les vulnérabilités les plus anciennes sont toujours les plus exploitées. Mi-2020, 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.

Cela souligne l’importance – aujourd’hui encore – d’une installation rapide des mises à jour de sécurité comme mécanisme de défense pour minimiser les risques cybers. Sans grande surprise donc, la gestion des vulnérabilités – pourtant l’une des plus anciennes pratiques de la cybersécurité – reste pour Wavestone[4] l’un des défis majeurs à relever pour les RSSI en 2021. Faut-il pour autant essayer de corriger toutes les vulnérabilités ? Petit retour dans le passé.

« Vulnerability Assessment » vs. « Vulnerability Management »

Quand elles sont apparues sur le marché, à la fin des années 90, les premières solutions de gestion des vulnérabilités avaient un fonctionnement proche de celui d’un antivirus : l’objectif était de détecter le plus grand nombre possible de menaces potentielles. On parlait plus volontiers de « scanners de vulnérabilités ».

Le volume de vulnérabilités était alors relativement faible par rapport à aujourd’hui. En 2000, le NVD recensait environ 1 000 nouvelles vulnérabilités sur l’année contre plus de 18 000 en 2020.

Un traitement exhaustif et manuel des vulnérabilités était alors encore possible. Les scanners fournissaient la liste des vulnérabilités, leur pertinence dans le contexte de l’entreprise était analysée par les équipes IT et un rapport était envoyé aux responsables métiers. Une fois le rapport approuvé, les administrateurs corrigeaient la vulnérabilité et procédaient à une nouvelle analyse pour vérifier la bonne mise en place du correctif.

Source : National Vulnerability Database (https://nvd.nist.gov/)

Pendant les deux décennies suivantes, le nombre de vulnérabilités découvertes a augmenté de façon constante avec une véritable explosion à partir de 2017, tendance qui s’est poursuivie jusqu’à aujourd’hui. En 2020, c’est un record de plus de 18 000 nouvelles vulnérabilités qui ont été recensées et publiées par le NIST. Mais non, les développeurs ne codent pas de plus en plus mal ! Différentes raisons expliquent le nombre croissant de vulnérabilités divulguées :

1. L’innovation et la digitalisation accélérée des métiers conduisent à une augmentation des produits matériels et logiciels publiés. En 2010, le NIST enregistrait 22 188 nouvelles entrées dans son référentiel CPE, dont 1 332 nouveaux produits et 406 éditeurs. En 2020, c’est 324 810 entrées (+1 460 %), 35 794 nouveaux produits (+2 690 %) et 6 060 éditeurs (+1 490%) qui font leur apparition.
2. La demande de réduction des délais de mise sur le marché pousse les éditeurs à réduire les cycles de développement pour commercialiser leurs produits plus rapidement quitte à rogner sur les ressources nécessaires pour l’assurance qualité et les tests de sécurité.
3. La cybercriminalité est devenue une activité lucrative. Un nombre de plus en plus important de vulnérabilités est aujourd’hui attribué aux cybercriminels à la recherche de nouveaux outils pour soutenir leurs attaques.
4. En parallèle, le nombre d’experts et d’organisations indépendantes qui participent à la recherche et à la découverte des vulnérabilités est en augmentation. La démocratisation et l’industrialisation des programmes de Bug-Bounty n’y sont d’ailleurs pas étrangères.
5. Et enfin, sauf rares exceptions comme dans le RGPD, en l’absence de législation et de réglementation adéquates pour protéger les droits des consommateurs en cas de vulnérabilités dans les logiciels, l’industrie n’est pas incitée à investir dans des produits plus sûrs et à assumer la responsabilité des dommages causés.

Cependant le problème ne se trouve pas seulement dans le nombre plus élevé de vulnérabilités recensées dans les bases du NVD ou d’autres référentiels. Avec l’avènement de l’ultra-mobilité, le home-office, le cloud-computing, les médias sociaux, l’IoT mais aussi la convergence entre IT et OT, les Systèmes d’Information n’ont cessé de se complexifier et de s’étendre, de s’ouvrir et de multiplier le nombre de leurs fournisseurs, … autant de potentielles nouvelles portes d’entrées pour les cybercriminels.

En parallèle, les entreprises conscientes des risques déploient et opèrent un arsenal de détection des vulnérabilités qui s’étoffe continuellement et qui a gagné en maturité ces dernières années, voir qui s’est « commoditizé » :

• Tests d’intrusions, Red-teams,
• Scanners de vulnérabilités : sur la totalité du parc externe et/ou interne
• Veille en vulnérabilités
• SAST, DAST & SCA : souvent directement intégrés aux pipelines de développement
• Campagnes de bug-bounty

Toutes ces pratiques de détection sont complémentaires et généralement empilées dans une approche « best-of-breed » pour évaluer des briques spécifiques du SI. Malheureusement, c’est souvent une fois l’arsenal mis en place que les problèmes sautent aux yeux (liste non exhaustive) :

• L’hétérogénéité des formats de rendu : rapports au format PDF ou Excel pour les pentests, résultats des scans dans la console de l’outils, vulnérabilités sur la plateforme de bug bounty, …, contraignent souvent l’entreprise à adopter une gestion des vulnérabilités en silo. Il en est de même pour le scoring des vulnérabilités qui s’avère finalement être un patchwork entre CVSS et ses multiples versions, échelles propriétaires et savant mélange des deux.
• En découle l’incapacité à prioriser globalement les efforts de remédiation du fait d’une perception parcellaire et hétérogène du stock de vulnérabilités.
• La gestion de volumes de données devenus bien trop importants pour être traités manuellement : il n’est pas rare qu’une entreprise qui réalise des scans authentifiés sur son parc voit son volume de vulnérabilités dépasser plusieurs millions d’entrées dans la console du scanner.
• La difficulté à coordonner les actions de remédiation : identification du propriétaire d‘un actif et du porteur d’une action, échanges de mails, suivi d’avancement, reporting Excel, …
• La frustration des équipes en charge de la remédiation qui ne disposent pas de reporting factuel traduisant l’effort de remédiation sur la posture globale de sécurité de l’entreprise.

Face à ces problèmes, les entreprises n’ont d’autres choix que de travailler à la mise en place de processus souvent coûteux car s’appuyant sur des actions manuelles, le développement d’un outillage ad-hoc ou encore un assemblage de bric et de broc de solutions glanées çà et là. Le manque d’automatisation de ce processus est d’autant plus absurde qu’il mobilise généralement de rares et coûteux experts en cybersécurité sur des tâches à faible valeur comme de la compilation de données dans Excel, la recherche sans fin des bons interlocuteurs ou encore le suivi de fils de mails.

Dans son étude « Cost and consequences of gaps in vulnerability management responses » (2019), le Ponemon Institute estime que les entreprises de plus de 10 000 salariés ont consacré en moyenne en 2019 plus de 21 000 heures (soit près de 12 ETP) à la prévention, détection et traitement des vulnérabilités. Cela représente un total de plus de 1M$ pour un rapport qualité/prix finalement très décevant.

Le « patching paradox »

En théorie, la meilleure façon de rester protégé est de maintenir à jour chaque système en corrigeant chaque nouvelle vulnérabilité, au fil de l’eau, dès qu’elle est identifiée. IRL, la tâche s’avère aujourd’hui impossible en raison d’un nombre de vulnérabilités devenues bien trop important mais aussi des ressources humaines ou financières limitées, de l’existence de systèmes hérités et des délais de mise à disposition ou des contraintes de déploiement des patchs.

En définitive, quelle que soit sa taille, une organisation n’aura jamais assez de ressources humaines ou financières pour remédier à toutes ses vulnérabilités. L’industrie appelle d’ailleurs « Patching Paradox » la conviction – erronée – que plus de personnel affecté aux traitements des vulnérabilités équivaut à une meilleure sécurité.

Afin de réduire la pression pour augmenter les effectifs à un moment où il y a une pénurie d’experts sécurité qualifiés et pour éviter que la gestion des vulnérabilités ne devienne une course effrénée et perdue d’avance à vouloir corriger toujours plus de vulnérabilités, il est nécessaire aujourd’hui pour les entreprises de déterminer celles qui doivent l’être en priorité.

Après avoir vu dans ce premier article l’état de la menace et les problématiques actuelles liées à la gestion des vulnérabilités, nous verrons dans un 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.

[1] Ponemon Institute – Cost and consequences of gapes in vulnerability management responses – 2019

[2] https://intel471.com/blog/ransomware-as-a-service-2020-ryuk-maze-revil-egregor-doppelpaymer/

[3] https://www.checkpoint.com/downloads/resources/cyber-attack-trends-report-mid-year-2020.pdf

[4] https://www.wavestone.com/fr/insight/radar-rssi-quelles-priorites-2021/

Cet article Hackuity | Shake’Up – Le futur de la gestion des vulnérabilités: état de la menace et problématiques actuelles de gestion des vulnérabilités (1/2) est apparu en premier sur RiskInsight.