De nombreuses organisations ont adopté la gestion des vulnérabilités fondée sur les risques comme élément central de leur programme de cybersécurité, allant au-delà d’un simple tri basé sur le CVSS pour mettre en place des cadres de hiérarchisation des priorités et investir dans des flux de renseignements sur les cybermenaces, des scanners, ainsi que des processus de correction des vulnérabilités . Pourtant, les files d'attente de correction restent souvent ingérables, les scores de risque peinent à gagner en crédibilité auprès des équipes informatiques, et les équipes ont toujours du mal à démontrer à la direction une réduction mesurable des risques.
Cet article vous explique comment combler chacune de ces lacunes, qu'il s'agisse de l'infrastructure de couverture, des modèles d'évaluation, de la coordination entre les équipes ou encore des indicateurs clés de performance (KPI) qui démontrent que votre programme réduit les risques, afin que votre équipe puisse faire face aux menaces auxquelles votre organisation est confrontée aujourd'hui.
Pourquoi la plupart des programmes RBVM piétinent avant de pouvoir se développer à grande échelle
Les organisations qui abandonnent les anciennes approches de gestion des vulnérabilités et de gestion des risques conservent souvent les mêmes faiblesses que le RBVM a été conçu pour surmonter : une visibilité incomplète sur les actifs, des résultats de scan non validés et des transferts de responsabilité peu clairs entre les équipes de sécurité et les opérations informatiques. Pourtant, la plupart des équipes constatent que comprendre les principes de la hiérarchisation des priorités en fonction des risques est la partie la plus facile. C'est lorsqu'il s'agit de les appliquer de manière cohérente dans tous les environnements d'entreprise que des défis supplémentaires apparaissent.
Le principe est simple. C'est au moment de l'exécution que les programmes rencontrent des problèmes.
Trois lacunes en matière d'infrastructure expliquent la plupart des défaillances du RBVM :
- Visibilité incomplète des actifs d' : Les scores de risque calculés à partir de données partielles sur les vulnérabilités n'offrent qu'une protection partielle. Si les terminaux ne sont pas gérés, ne font pas l'objet d'analyses ou fournissent des données obsolètes, la file d'attente des risques présente un angle mort qu'aucun modèle de hiérarchisation ne peut combler.
- Résultats de scan non validés : Les résultats d'un scan ne correspondent pas nécessairement à une exposition confirmée. Dans les environnements où les données d'analyse sont obsolètes ou où la gestion des actifs laisse à désirer, les taux de faux positifs peuvent être suffisamment élevés pour que les équipes informatiques perdent confiance dans la file d'attente et que les temps de réponse s'allongent de manière générale.
- Absence de modèle de transfert réglementé : la sécurité « » identifie et hiérarchise les priorités. Le service informatique met en œuvre les mesures correctives. En l'absence de responsabilités clairement définies, de SLA classés par niveau de risque et d'une gestion des exceptions, les constatations s'accumulent sans suite.
La condition préalable à la couverture
La précision des scores de risque cyber dépend entièrement de la qualité de l'inventaire des actifs et des données relatives à l'état des terminaux sur lesquelles ils sont calculés. La couverture ne se mesure pas uniquement au nombre d'actifs. Cela dépend de la possibilité de connaître en permanence leur configuration actuelle, l'état de leurs correctifs et leur niveau d'exposition. Sans cela, les modèles de hiérarchisation s'appuient sur une représentation incomplète du risque.
Lorsque des lacunes de couverture apparaissent
Les environnements d'entreprise génèrent des lacunes de couverture à des endroits prévisibles. Les appareils non gérés, les ordinateurs portables des sous-traitants, les appareils mobiles, les conteneurs, les actifs OT et ICS, les appareils IoT, l'informatique parallèle et les terminaux équipés d'agents obsolètes ou ne transmettant pas de rapports ne sont pas pris en compte dans l'analyse standard.
Les actifs OT et ICS nécessitent une stratégie de protection différente. Beaucoup ne peuvent pas prendre en charge les agents traditionnels, les analyses agressives risquent d'entraîner des perturbations opérationnelles, et il est fréquent de rencontrer des logiciels hérités pour lesquels aucun correctif n'est disponible. Pour ces actifs, ce sont les contrôles compensatoires qui constituent le principal levier de réduction des risques, et non les mesures correctives ; la planification de la couverture doit en tenir compte dès le départ.
Les environnements de développement présentent un angle mort similaire : les vulnérabilités introduites par les pipelines CI/CD DevOps passent souvent inaperçues jusqu’à ce qu’elles atteignent l’environnement de production, où leur correction s’avère bien plus perturbante.
Une vulnérabilité détectée sur 200 terminaux gérés peut également exister sur 50 appareils non gérés qui n'apparaissent jamais dans la file d'attente des risques. L'image semble complète, mais l'exposition réelle est plus large que ce qui est visible.
Pourquoi le décalage de balayage nuit au score
Les analyses périodiques génèrent des résultats de notation qui reflètent un état passé, et non la surface d'attaque actuelle. Dans des environnements dynamiques où les cycles de correctifs, les déploiements et les modifications de configuration se succèdent sans discontinuer, même un léger retard dans l'analyse peut avoir pour conséquence que le score de risque ne reflète plus l'exposition réelle.
La visibilité en temps réel sur les terminaux réduit le délai lié aux analyses périodiques, ce qui permet d'établir des scores de risque sur une base plus précise. Les plateformes conçues pour la surveillance continue « » ( ) fournissent des données télémétriques sur les terminaux mises à jour régulièrement, ce qui permet de prendre des décisions de priorisation reflétant la situation réelle plutôt qu'un instantané datant de plusieurs jours.
La visibilité des actifs n'est pas un projet ponctuel. C'est une discipline qui se pratique en continu. Sans cela, même le modèle de notation le plus sophistiqué produit des classements qui ne reflètent pas les conditions de risque réelles.
Une fois la visibilité en temps réel mise en place, la question suivante se pose : comment établir un score de risque auquel les équipes feront confiance ?
Comment les scores de risque sont-ils réellement calculés ?
Un score de risque auquel personne ne fait confiance est pire que l'absence totale de score. Une évaluation efficace des risques repose sur une méthodologie claire et transparente, dans laquelle les éléments pris en compte, la pondération et la logique d'attribution des notes sont bien compris tant par les équipes chargées de la sécurité que par celles chargées des opérations informatiques. Pour instaurer la confiance, il faut expliquer clairement comment ces données et ces pondérations s'articulent pour aboutir à un score.
Tout aussi important, les équipes doivent avoir l'assurance que les données sous-jacentes reflètent l'état réel du système et non des instantanés obsolètes, afin que les décisions de priorisation soient exploitables.
Quelles sont les quatre données principales utilisées pour le calcul des scores de risque RBVM ?
Les scores de risque RBVM combinent la gravité de base selon le CVSS (gravité de la faille technique), la probabilité d'exploitation selon l'EPSS (probabilité d'une exploitation dans la réalité), le statut KEV de la CISA (confirmation d'une exploitation active) et la criticité de l'actif (fonction métier et sensibilité des données) afin d'établir un ordre de priorité des risques réels.
| Saisie | Ce qu'il mesure | Pourquoi est-ce important ? |
|---|---|---|
| Niveau de gravité de base selon le CVSS | Gravité technique de la faille | Fournit une référence en matière de gravité, mais le score de base ne tient pas compte du contexte réel ni de la possibilité d'exploitation* |
| Probabilité d'exploitation de l'EPSS | Risque d'exploitation dans la nature | Signal dynamique qui reflète le comportement actuel des acteurs malveillants et évolue à mesure que de nouvelles activités d'exploitation sont observées |
| Statut CISA KEV | Que cette vulnérabilité fasse l'objet d'une exploitation active ou non | Indicateur binaire de la mise en service effective d'une arme |
| Importance stratégique des actifs | Fonction métier, sensibilité des données, exposition | Détermine le rayon d'action de l'explosion si l'élément est compromis |
* Le CVSS v3.x comprend des modificateurs de score temporels et environnementaux destinés à apporter du contexte, mais ceux-ci sont rarement mis en œuvre à grande échelle dans les programmes d'entreprise.
Ces données sont d'autant plus efficaces qu'elles sont constamment mises à jour avec les dernières informations sur les vulnérabilités, notamment les données relatives aux exploits récemment révélés, aux nouvelles techniques utilisées par les attaquants et aux scores actualisés de probabilité d'exploitation. Le contexte des menaces, notamment les secteurs d'activité activement ciblés et les kits d'exploitation en circulation, permet d'affiner davantage la pondération des scores pour votre environnement spécifique.
Le potentiel de propagation latérale, c'est-à-dire la position au sein du réseau et les voies d'exposition de l'actif concerné, constitue également un facteur supplémentaire de modification du risque. Une vulnérabilité présente sur un serveur de test isolé comporte un risque différent de celui que représente la même vulnérabilité sur un contrôleur de domaine ou un serveur d'applications situé sur un chemin d'accès au réseau menant à des données sensibles des clients.
Pourriez-vous donner un exemple d'approche fondée sur les risques ?
Examinons ces deux vulnérabilités :
Vulnérabilité A : CVSS 9,8 (critique), EPSS 0,02 (faible probabilité d'exploitation), ne figure pas sur la liste KEV de la CISA, affecte un serveur de test isolé ne présentant aucune voie de propagation latérale.
Vulnérabilité B : CVSS 7,5 (risque élevé), EPSS 0,85 (probabilité d'exploitation élevée), répertoriée dans la liste KEV de la CISA, affecte un serveur de traitement des paiements en production disposant d'un accès latéral à la base de données clients.
Le CVSS, à lui seul, donnerait la priorité à A par rapport à B. Cependant, un modèle basé sur les risques de l’ attribue à juste titre une priorité plus élevée à B, car un serveur de paiement en production offrant des voies de déplacement latéral vers des données sensibles représente le type de cible de grande valeur et accessible que les campagnes de ransomware et d’extorsion ont pour habitude de cibler.
C'est précisément ce revirement qui constitue l'intérêt même de la hiérarchisation des vulnérabilités dans un programme fondé sur les risques.
Toutefois, la hiérarchisation des risques ne suffit pas à elle seule à réduire les risques, à moins qu'elle ne débouche sur des mesures correctives qui soient menées à bien et vérifiées.
Les proportions spécifiques varient selon les organisations et leur tolérance au risque, mais le principe général reste le même : les signaux dynamiques liés aux menaces et le contexte opérationnel peuvent et doivent primer sur la gravité statique.
La notation joue également un rôle dans la gestion de la mise en œuvre des mesures correctives, et pas seulement dans la définition des priorités. À mesure que les programmes évoluent vers l'automatisation, l'évaluation de la fiabilité peut aider à déterminer quelles actions peuvent être mises en œuvre en toute sécurité à grande échelle sans intervention humaine, et lesquelles nécessitent un déploiement progressif ou une validation manuelle.
Une vulnérabilité présentant un niveau de risque élevé, mais pour laquelle il existe une incertitude quant à la stabilité du correctif sur une version spécifique du système d'exploitation, peut justifier un déploiement progressif plutôt qu'une mise en œuvre immédiate. C'est en alignant les seuils de confiance sur les processus de correction que les organisations développent l'automatisation sans accroître le risque opérationnel.
Mais même un score bien conçu n'a d'utilité que si le résultat sous-jacent est réel. C'est là que la validation entre en jeu.
Vérifier les expositions avant d'agir
Un résultat de dépistage n'équivaut pas à une exposition confirmée. Agir sur la base de conclusions non vérifiées constitue un gaspillage des capacités d'assainissement et sape la confiance entre les équipes, sur laquelle reposent les programmes RBVM. La validation permet aux équipes de combler cet écart avant qu'il ne s'aggrave.
Que signifie la validation ?
Une exposition confirmée désigne un résultat dont la présence sur le point terminal a été vérifiée et qui n'a pas encore été atténué par des mesures de contrôle compensatoires, sur la base de l'état actuel du point terminal et des données de configuration. La validation répond à trois questions :
- La version du logiciel vulnérable est-elle réellement installée et en cours d'exécution ?
- Une mesure de contrôle compensatoire permet-elle déjà d'atténuer le risque ? La segmentation du réseau, les règles WAF et le renforcement de la configuration peuvent toutes contribuer à réduire la vulnérabilité aux attaques.
- Ce bien est-il toujours en service et accessible ?
Grâce à ce niveau de confiance, les organisations peuvent en toute sécurité automatiser les étapes de correction sans introduire de nouveaux risques dans le processus.
Pourquoi les faux positifs sapent la confiance
Dans les environnements d'entreprise, les taux de faux positifs varient considérablement en fonction de la configuration du scanner, de l'état des actifs et de la date de la dernière analyse. Quel que soit le chiffre exact, même un taux de faux positifs modeste, à grande échelle, peut submerger les capacités des équipes informatiques si les résultats ne sont pas validés avant d'être intégrés à la file d'attente des mesures correctives. Des analyses de vulnérabilité obsolètes, des mesures de contrôle compensatoires non prises en compte et des actifs déjà mis hors service sont autant de facteurs qui contribuent à cette situation.
Chaque faux positif qui parvient au service informatique fait perdre du temps qui aurait pu être consacré à la résolution du risque. Au fil du temps, les équipes informatiques commencent à considérer cette file d'attente avec scepticisme. Les réponses tardent à venir, et la file d'attente perd de sa crédibilité.
C'est la gestion des exceptions qui fait la différence entre une file d'attente propre et une file d'attente encombrée. Des procédures formelles permettant d'écarter les risques acceptés, les expositions compensées et les constatations relatives aux actifs mis hors service garantissent que la file d'attente active ne reflète que les expositions réelles et non résolues. Sans ce mécanisme, même les files d'attente dont les priorités sont bien définies accumulent du bruit, ce qui, au fil du temps, sape la confiance des équipes informatiques.
Pour rétablir la confiance, les organisations ont besoin de bien plus que de meilleurs modèles de classement. Ils doivent avoir l'assurance que les problèmes identifiés reflètent la situation actuelle et que les mesures correctives mises en œuvre sont efficaces.
Cela signifie qu'il faut vérifier si les mesures correctives entraînent des changements avérés dans l'état du système, et pas seulement la clôture d'un ticket ou une mise à jour de son statut.
Comment Tanium facilite la gestion des vulnérabilités basée sur les risques
La plupart des organisations savent déjà quelles sont les vulnérabilités les plus importantes. Le plus difficile est de mettre ces connaissances en pratique rapidement, de manière cohérente et à grande échelle. La solution « Tanium Exposure Management » comble les lacunes de mise en œuvre qui entravent le bon déroulement des programmes de gestion des vulnérabilités basés sur les risques, en réunissant sur une seule et même plateforme la visibilité en temps réel, la hiérarchisation, la correction et la validation.
Visibilité des actifs en temps réel
Tanium surveille en permanence les terminaux, les appareils non gérés, les registres de conteneurs et les charges de travail Kubernetes afin de détecter les vulnérabilités et les lacunes en matière de conformité. Tanium Cloud Workloads étend cette couverture aux environnements conteneurisés grâce à la visibilité sur le registre d'images et à l'analyse des vulnérabilités, à l'analyse des conteneurs en exécution, ainsi qu'à l'application des politiques Kubernetes. Les lacunes de couverture s'amenuisent, car la plateforme détecte des actifs que d'autres outils ne repèrent pas.
Évaluation des risques fondée sur la situation actuelle
Les scores de risque au niveau des terminaux et au niveau organisationnel tiennent compte à la fois de la gravité des vulnérabilités, de la criticité des actifs, des manquements à la conformité et du risque de déplacement latéral — autant de facteurs que les scores CVSS statiques ne prennent pas en compte —, ainsi que d'une analyse comparative par rapport à des références du secteur. Les scores reflètent l'état actuel des terminaux plutôt que des instantanés ponctuels pris à intervalles réguliers. La solution « Tanium Benchmark » permet aux responsables de la sécurité de comparer leur niveau de risque à celui de leurs homologues du secteur, en transformant les données relatives aux vulnérabilités en indicateurs axés sur les résultats dont ont besoin les équipes de direction et de conformité.
Assainissement intégré
Les équipes passent de l'analyse à l'action sur la même plateforme. Les correctifs, les modifications de configuration et autres mesures de contrôle peuvent être appliqués à grande échelle sans avoir à passer d'un outil à l'autre. La plateforme Tanium Comply permet de réaliser des évaluations de vulnérabilité et des contrôles de conformité portant sur les systèmes d'exploitation, les applications, la chaîne d'approvisionnement logicielle et les configurations de sécurité, à l'aide de contenus SCAP et OVAL, ainsi que de la bibliothèque de contenus propre à Tanium, mise à jour quotidiennement.
Automatisation contrôlée
Tanium Automate permet aux équipes de créer des guides d'intervention « no-code » et « low-code » qui automatisent les tâches de correction récurrentes. Les playbooks peuvent nécessiter l'autorisation d'un opérateur avant leur exécution, ce qui permet de garantir la traçabilité à grande échelle.
Validation en boucle fermée
Une fois le correctif appliqué, l'exécution de l'évaluation Comply permet de vérifier si la vulnérabilité a été corrigée et met à jour le score de risque en conséquence. Tanium peut effectuer cette évaluation à la demande, sans qu'il soit nécessaire de lancer un cycle d'analyse complet programmé.
Espace de travail unifié dédié à l'informatique et à la sécurité
Les deux équipes s'appuient sur les mêmes scores de risque, les mêmes données de hiérarchisation et le même état d'avancement des mesures correctives, le tout au sein d'une plateforme unique et unifiée. Ce modèle opérationnel partagé contribue à réduire les efforts de coordination qui ralentissent la résolution des incidents lorsque les équipes de sécurité et d'exploitation informatique s'appuient sur des outils et des sources de données distincts.
Tanium Guardian
Tanium Guardian met en évidence les menaces émergentes grâce à des conseils élaborés par des experts de l'équipe d'intervention d'urgence en matière de vulnérabilités (VERT) de Tanium, aidant ainsi les équipes à faire face en toute confiance aux failles « zero-day » et aux risques nécessitant une réaction rapide. Les équipes peuvent mettre en œuvre des mesures correctives directement au sein de la plateforme informatique autonome Tanium.
Ces fonctionnalités agissent de concert pour raccourcir le cycle allant de la détection à la correction validée. Ring Power Corp. a utilisé Tanium pour recenser ses Log4j vulnérabilités sur l'ensemble de ses terminaux en environ 30 minutes, un travail qui, selon les estimations de l'équipe, aurait pris des mois avec les outils utilisés auparavant.
Lorsque la détection, la hiérarchisation et la correction s'appuient sur une plateforme unique, les programmes de gestion des vulnérabilités basés sur les risques peuvent évoluer au rythme imposé par l'évolution des menaces.
Foire aux questions sur la gestion des vulnérabilités basée sur les risques
Même les cadres théoriques les mieux compris soulèvent des questions pratiques liées à leur mise en œuvre, et le RBVM ne fait pas exception. Les réponses suivantes abordent certaines des sources de confusion les plus courantes auxquelles les équipes sont confrontées lors de la mise en œuvre du RBVM.
En quoi la gestion des vulnérabilités RBVM diffère-t-elle de la gestion traditionnelle des vulnérabilités ?
La gestion traditionnelle des vulnérabilités établit ses priorités en se basant uniquement sur les scores de gravité CVSS, tandis que la RBVM prend en compte à la fois la probabilité d'exploitation et le niveau de criticité des actifs afin de se concentrer sur les vulnérabilités qui présentent un risque réel pour l'entreprise. Par exemple, une faille notée CVSS 7,5 sur un serveur de paiement présentant un niveau d'exploitabilité élevé peut être considérée comme plus grave qu'une faille notée CVSS 9,8 sur un système de test isolé.
En quoi la gestion des vulnérabilités fondée sur les risques améliore-t-elle les défenses en matière de cybersécurité ?
RBVM renforce les défenses en orientant les ressources de correction vers les vulnérabilités que les attaquants exploitent activement ou qu'ils sont le plus susceptibles d'utiliser à des fins malveillantes. Cela permet de réduire le délai moyen de correction pour les vulnérabilités les plus critiques et permet aux équipes informatiques de se concentrer sur les résultats qui présentent un risque réel.
Quels sont les meilleurs outils pour mettre en œuvre une gestion des vulnérabilités fondée sur les risques ?
Pour être efficaces, les programmes RBVM doivent généralement disposer de capacités dans plusieurs domaines : découverte et inventaire continus des actifs, analyse et enrichissement des vulnérabilités (y compris les scores EPSS et le statut KEV de la CISA), intégration des flux de travail avec les outils ITSM pour l'attribution des mesures correctives, et vérification que les correctifs déployés ont bien résolu le problème identifié.
Certaines organisations mettent en place ces capacités à partir de plusieurs outils ponctuels. D'autres regroupent la visibilité des actifs, l'évaluation des risques et les mesures correctives au sein d'une plateforme de flux de travail unique. L'approche à adopter dépend de la pile d'outils existante, de la structure de l'équipe et du fait que la visibilité sur les terminaux soit déjà un problème résolu ou non.
La plateforme informatique autonome Tanium associe les informations en temps réel sur les terminaux à des flux de travail intégrés et à des mesures correctives, afin d'aider les équipes de sécurité et informatiques à travailler à partir d'une vision commune et précise des risques.
Les équipes peuvent agir plus rapidement, réduire les délais de transfert et vérifier les résultats des mesures correctives dans l'ensemble de l'environnement sans avoir à recourir à un suivi manuel ni à des données obsolètes.
Savoir quelles sont les vulnérabilités les plus importantes ne représente que la moitié du chemin. C'est précisément dans la résolution rapide, cohérente et à grande échelle de ces problèmes que la plupart des programmes se heurtent à des obstacles.
Prenez rendez-vous dès aujourd'hui pour une démonstration gratuite et personnalisée afin de découvrir comment Tanium associe visibilité en temps réel, hiérarchisation des priorités et correction des problèmes au sein d'une seule et même plateforme.
