La plupart des programmes de gestion des vulnérabilités se qualifient eux-mêmes de « continus ». Peu d'entre eux le sont réellement. La différence est importante : un programme qui effectue des analyses hebdomadaires mais se présente comme « continu » suscite une fausse impression de sécurité, laissant des failles exposées entre deux cycles tandis que la direction part du principe que la couverture est totale.
La gestion continue des vulnérabilités (CVM) est un processus continu et automatisé visant à détecter, analyser, hiérarchiser et corriger les failles de sécurité au sein de l'infrastructure informatique d'une organisation. Contrairement aux cycles périodiques d'analyse et de rapport, le CVM offre une visibilité en temps réel sur l'état des actifs et leur niveau de vulnérabilité, réduisant ainsi le délai dont disposent les pirates pour exploiter les failles récemment révélées.
Cet article propose un cadre de diagnostic permettant d'évaluer si votre programme actuel répond à la norme opérationnelle que le terme « continu » implique, en abordant les conditions spécifiques, les indicateurs et les structures de coordination qui distinguent les programmes véritablement continus de ceux qui sont simplement fréquents.
Ce que signifie réellement le terme « continu » et pourquoi la plupart des programmes ne répondent pas à cette définition
La plupart des programmes qui se qualifient de « continus » fonctionnent encore selon des cycles d'analyse hebdomadaires ou mensuels. Ils traitent les priorités par lots, créent des tickets manuellement et partent du principe que la correction a fonctionné sans la vérifier. Par ailleurs, la surface d'attaque de l' ne cesse d'évoluer : de nouvelles ressources apparaissent, les configurations dérivent et les vulnérabilités (CVE) récemment divulguées créent des failles de sécurité que les cycles d'analyse hebdomadaires ne parviennent pas à combler.
Les programmes périodiques permettent de planifier des analyses, de hiérarchiser les tâches par lots et de créer manuellement des tickets. Les programmes en continu assurent un suivi en temps réel de l'état du système, déclenchent une hiérarchisation des priorités lorsque les conditions changent et vérifient la mise en œuvre des mesures correctives grâce à des contrôles en boucle fermée.
Un programme véritablement continu remplit toutes les conditions suivantes :
- Les nouveaux actifs sont détectés et répertoriés en quelques heures, et non en quelques jours
- Les vulnérabilités récemment identifiées sont évaluées par rapport à l'inventaire complet des actifs, dans le cadre d'un SLA défini
- Le statut de la remise en état est vérifié par le programme, et non présumé
La plupart des programmes ne répondent pas à au moins l'une de ces propriétés, et cela s'explique généralement par leur position sur l'échelle de maturité en matière de suivi.
Trois niveaux de continuité de la surveillance : périodique, à haute fréquence et en temps réel
Comprendre où se situe votre programme sur l'éventail de la surveillance continue des vulnérabilités permet de mieux cerner le coût réel de cette « surveillance continue » et d'identifier les lacunes qui subsistent.
Niveau 1 : Analyse périodique. Les analyses programmées sont exécutées chaque semaine, chaque mois ou chaque trimestre. Le délai de détection des vulnérabilités se mesure en jours, voire en semaines. Il existe des lacunes de couverture entre les cycles. Cette approche fonctionne dans des environnements stables et peu sujets aux changements, mais ne permet pas de détecter les vulnérabilités qui apparaissent en cours de cycle.
Niveau 2 : Balayage à haute fréquence. Des cycles d'analyse quotidiens ou quasi quotidiens réduisent le délai de détection à quelques heures. La couverture s'améliore dans les environnements dynamiques, mais les ressources éphémères telles que les conteneurs et les instances cloud à dimensionnement automatique (y compris les charges de travail s'exécutant dans des clusters Kubernetes qui peuvent être lancées et arrêtées au cours d'un même intervalle d'analyse) peuvent toujours exister entre deux fenêtres d'analyse et passer inaperçues.
Niveau 3 : Surveillance de l'état en temps réel basée sur des agents. Les agents persistants transmettent en continu des informations sur l'état et la configuration des ressources. Le délai de détection est ramené à quelques minutes. Les ressources éphémères et celles qui se reconnectent hors ligne sont prises en charge. Le compromis réside dans les coûts liés au déploiement et à la gestion des agents.
| Niveau | Latence de détection | Couverture des actifs | Le choix le plus adapté |
|---|---|---|---|
| Périodique | De quelques jours à quelques semaines | Intervalles entre les cycles | Des environnements stables et peu sujets aux changements |
| Haute fréquence | Horaires | Manque d'actifs éphémères | Une infrastructure dynamique mais prévisible |
| En temps réel | Procès-verbal | Couvre les ressources hors ligne/éphémères | Environnements de grande envergure, distribués ou en évolution rapide |
La plupart des programmes d'entreprise fonctionnent au niveau 1 ou 2 et partent du principe qu'ils sont « continus ». L'architecture à agent unique de Tanium fournit des données d'état en temps réel qui éliminent le décalage de latence inhérent aux analyses de vulnérabilité programmées . La question n'est pas de savoir quel niveau est le « meilleur ». Il s'agit de déterminer quel niveau correspond au profil de risque et au rythme de changement de votre environnement.
Le niveau de surveillance détermine la rapidité avec laquelle vous détectez les vulnérabilités. Ce qui va se passer ensuite déterminera si le fait de les retrouver a de l'importance.
Les points faibles des programmes CVM d'entreprise : le manque de coordination entre les services informatiques et SecOps
Une détection sans mesure corrective n'est qu'une campagne de sensibilisation coûteuse. La principale défaillance en matière de continuité des activités dans le domaine de la gestion de la valeur d'entreprise (CVM) n'est pas d'ordre technologique. C'est un problème de coordination qui empêche les équipes de corriger les vulnérabilités détectées à la vitesse exigée par le programme. Ce manque de coordination a des conséquences concrètes : les études montrent systématiquement que de nombreuses fuites de données ne sont pas dues à des vulnérabilités non détectées, mais à des vulnérabilités connues qui n’ont pas été corrigées, car personne n’assumait la responsabilité de la coordination entre les équipes de sécurité et les services informatiques.
Les équipes de sécurité détectent les vulnérabilités. La mise en œuvre des mesures correctives dépend des équipes informatiques, qui ont chacune des priorités, des accords de niveau de service (SLA) et des processus de gestion des changements différents. C'est dans l'écart entre « nous l'avons détecté » et « nous l'avons corrigé » que réside le risque.
Problèmes d'intégration du système de billetterie. Lorsque la détection de vulnérabilités nécessite la création manuelle d'un ticket, il est fréquent que les retards s'étendent sur plusieurs jours. La gestion intégrée des tickets fonctionne différemment : les rapports génèrent automatiquement des tickets accompagnés d'une indication de gravité, du contexte de l'actif et de recommandations de résolution. Les transferts manuels entraînent des frictions qui s'accumulent au fil des milliers de résultats.
Désalignement SLA. La sécurité définit le niveau de gravité à l'aide du score CVSS ou du score de risque. Le service informatique définit les priorités en fonction de la disponibilité des créneaux de mise en œuvre et de l'impact sur l'activité. En l'absence de niveaux de SLA communs, les vulnérabilités critiques restent en attente tandis que les équipes se disputent au sujet de leur planification.
Voici à quoi pourrait ressembler une structure pratique de SLA :
- Niveau 1 (critique, activement exploité) : SLA de résolution sous 24 heures
- Niveau 2 (risque élevé, faille exploitable) : SLA de 7 jours (réalisable à grande échelle grâce à l'application automatisée des correctifs ; à adapter en fonction de la complexité de l'environnement)
- Niveau 3 (moyen/faible) : Fenêtre de maintenance dont le risque est accepté ou planifiée
Ambiguïté quant à la propriété. Lorsque personne n'assume la responsabilité du processus de correction de bout en bout, les vulnérabilités s'accumulent dans les files d'attente des tickets. Un processus de correction clairement défini apporte une réponse à trois questions : Qui est responsable du ticket ? À qui appartient la vérification ? À qui incombe la responsabilité de l'exception si la mise en conformité est reportée ?
À quoi ressemble donc concrètement un programme véritablement continu ? La section suivante décompose ce concept en cinq conditions vérifiables.
Les cinq conditions auxquelles doit satisfaire un programme véritablement continu
Considérez ce qui suit comme une liste de contrôle, et non comme un cycle de vie. Chaque condition est soit remplie, soit non remplie. L'octroi d'un crédit partiel ne réduit pas l'exposition.
1. Inventaire complet des actifs en temps réel
Le programme tient à jour un inventaire en temps réel ( ) qui recense les actifs éphémères, distants et hors ligne. Pas une CMDB qui accuse un retard de plusieurs jours, voire de plusieurs semaines, par rapport à la réalité.
Test : Pouvez-vous confirmer, dans un délai d'une heure, si une vulnérabilité CVE critique récemment divulguée affecte un élément quelconque de votre environnement ? Si la réponse est « il faudrait d'abord effectuer une analyse », cela signifie qu'il y a une faille dans la continuité.
2. Détection pilotée par les événements
Les nouvelles vulnérabilités déclenchent les processus de détection dès leur divulgation, et non lors de la prochaine fenêtre d'analyse. Cela nécessite une intégration active avec les flux de renseignements sur les menaces de l' ainsi qu'avec les avis de sécurité des éditeurs, notamment les mises à jour KEV de la CISA, les publications du NVD et les bulletins spécifiques aux éditeurs tels que le « Patch Tuesday » de Microsoft et les avis relatifs aux distributions Linux, afin que les événements de divulgation déclenchent automatiquement une évaluation des actifs plutôt que d'attendre une analyse programmée.
Test : Lorsqu’une vulnérabilité CVE critique est publiée, combien de temps faut-il à votre programme pour analyser l’ensemble de vos ressources à la lumière de cette vulnérabilité ? Le service est assuré sans interruption. C'est un phénomène fréquent. La durée d'une semaine est périodique.
3. Hiérarchisation contextuelle intégrée au flux de travail
La hiérarchisation s'appuie sur la criticité des actifs, sur des indicateurs d'exploitabilité tels que l'EPSS et le KEV de la CISA, ainsi que sur les renseignements sur les menaces (notamment les menaces émergentes qui, bien qu'elles ne présentent pas encore de scores CVSS élevés, font l'objet d'une exploitation active dans la nature). Le système de notation de prédiction d'exploitation (EPSS) estime la probabilité qu'une vulnérabilité soit exploitée en conditions réelles dans un délai de 30 jours, fournissant ainsi une indication prospective que la gravité CVSS à elle seule ne permet pas de saisir. Il s'agit du site consacré à la gestion des vulnérabilités basée sur les risques, qui présente la méthodologie.
4. Correction avec vérification en boucle fermée
Chaque mesure corrective est vérifiée par un programme. La vulnérabilité n'est pas considérée comme « résolue » tant qu'un contrôle de suivi n'a pas confirmé que le problème a été corrigé. L' « Correction automatisée des vulnérabilités » présente différentes approches de mise en œuvre.
5. Mesure et rapport continus
Le programme suit ses propres indicateurs de performance et les communique aux parties prenantes selon une fréquence définie. Pas seulement lorsque les auditeurs le demandent. Si vous ne pouvez pas répondre à la question « Quel est notre délai moyen de correction des vulnérabilités critiques ? », Sans générer de rapport personnalisé, le programme fournit des informations à la demande et n'effectue pas de mesure en continu.
Le non-respect d'une seule de ces conditions entraîne un risque. Un programme offrant une détection parfaite mais aucune vérification rend compte de l'activité, et non des résultats.
Parmi ces cinq étapes, la vérification est celle que la plupart des équipes négligent complètement. Voyons pourquoi cela est important.
Validation : l'étape du CVM que la plupart des programmes négligent
La plupart des équipes considèrent qu'une vulnérabilité est « résolue » dès le déploiement d'un correctif, et non lorsqu'il est confirmé que la faille a été comblée. Cet écart entre « nous avons mis en place la correction » et « la correction a effectivement fonctionné » est à l'origine d'une fausse confiance.
Avant la remise en état
Confirmation préalable à la remise en état
Avant d'attribuer une vulnérabilité en vue de sa correction, assurez-vous que le résultat détecté par le scanner correspond bien à une faille réelle et exploitable. Il ne s'agit ni d'un faux positif ni d'un artefact de configuration. Cette étape permet également de détecter les erreurs de configuration que les scanners identifient comme des vulnérabilités : il s'agit de problèmes qui peuvent nécessiter une modification de configuration plutôt qu'un correctif, et qui sont mal acheminés lorsque le triage préalable à la correction est ignoré. Si vous négligez cette étape, vous gaspillez des ressources informatiques et, à terme, vous sapez la confiance accordée au programme de machines virtuelles.
Une fois le correctif déployé
Vérification après la remise en état
Une fois qu'un correctif de sécurité ou une modification de configuration a été déployé(e), veuillez vérifier par programmation que la vulnérabilité est bien corrigée. Une nouvelle analyse ou une vérification de l'état via un agent confirme que la vulnérabilité n'existe plus sur le système. « Le ticket est clôturé » ne constitue pas une vérification.
Pour les actifs de grande valeur
Validation antagoniste
Pour les actifs de grande valeur ou les étapes clés de la remise en état, les tests d'intrusion offrent un niveau de validation par simulation d'attaques que la vérification automatisée ne peut pas reproduire. Les nouvelles analyses programmatiques confirment qu’une vulnérabilité spécifique a été corrigée ; un test ciblé va plus loin. Des contrôles automatisés permettent de vérifier qu'un dossier est bien clôturé. Ils ne peuvent pas confirmer que l'exposition a pris fin.
Lorsque la remise en état n'est pas possible
Gestion des exceptions
Pour les vulnérabilités qui ne peuvent pas être corrigées, comme dans le cas des systèmes hérités ou des applications critiques pour l'activité soumises à un gel des modifications, définissez une procédure d'exception formelle. Consignez l'acceptation des risques, les contrôles compensatoires, la fréquence des revues et les dates d'expiration. Les exceptions sans date d'expiration constituent un risque permanent.
Un programme de gestion des vulnérabilités (CVM) qui ne parvient pas à démontrer l'efficacité des mesures correctives évalue la charge de travail, et non la sécurité.
La vérification permet de déterminer si les corrections apportées individuellement ont été efficaces. Les indicateurs permettent de déterminer si le programme lui-même fonctionne. Voici comment faire la différence.
Comment évaluer l'efficacité de votre programme CVM
Les indicateurs sont le seul moyen de distinguer un programme véritablement continu d'un programme qui se contente d'être fréquent. Suivez les éléments suivants, rendez-en compte régulièrement et utilisez-les pour favoriser l'amélioration. Pris dans leur ensemble, ces indicateurs offrent à la direction une vision quantifiable du niveau de sécurité de l’organisation : il ne s’agit pas seulement d’un aperçu des tickets en cours, mais d’une courbe de tendance montrant si le programme parvient réellement à réduire le risque cyber au fil du temps.
| Système métrique | Ce qu'il mesure | Référence en matière de santé |
|---|---|---|
| Pourcentage de couverture de numérisation | Proportion des actifs connus faisant l'objet d'un suivi actif | Près de 100 %, avec des exceptions avérées |
| Nombre d'heures entre la publication de la vulnérabilité (CVE) et la confirmation de son impact | Quelques heures pour les vulnérabilités critiques (CVE), et non pas plusieurs jours | |
| Temps moyen de résolution (MTTR) | Délai entre la détection et la résolution vérifiée, par niveau de gravité | Dans le cadre des niveaux de SLA définis |
| Taux de faux positifs | Pourcentage de résultats non exploitables | En baisse au fil du temps |
| Taux d'exception | Pourcentage des constatations pour lesquelles le risque a été accepté par rapport à celles ayant fait l'objet de mesures correctives | Stables ou en baisse, tous les chiffres sont documentés |
| Taux de validation des mesures correctives | Pourcentage des constatations « résolues » vérifiées par le programme | Près de 100 % pour les niveaux « critique » et « élevé » |
L'évolution des vulnérabilités constitue un septième indicateur facultatif : pendant combien de temps les vulnérabilités restent-elles non corrigées dans l'ensemble de l'environnement au fil du temps ? Une répartition équilibrée privilégie une résolution rapide, avec un âge maximal acceptable défini pour chaque niveau de gravité et des attentes claires concernant les délais de correction.
Si la direction ne prend connaissance des données relatives à la vulnérabilité que lorsque le service chargé de la conformité le lui demande, cela signifie que le programme se contente de fournir des rapports à la demande, sans procéder à une évaluation continue ni à une gestion proactive des risques.
Les indicateurs vous permettent de savoir si le programme fonctionne. Elles ne tiennent pas compte des réalités opérationnelles qui compliquent la mise en œuvre. La manière dont un programme répond à ces exigences varie lorsque l'environnement lui-même est complexe et distribué.
La gestion de la valeur d'entreprise (CVM) dans des environnements complexes et réglementés
Les environnements complexes ne dispensent pas un programme des conditions de continuité définies précédemment. Elles ajoutent des contraintes opérationnelles auxquelles le programme s'adapte.
- Terminaux distribués et hors ligne : Les agents distants peuvent fonctionner avec une connexion intermittente. Les programmes en continu gèrent cela grâce à la synchronisation des états lors de la reconnexion, à la mise en file d'attente des actions correctives et au suivi des lacunes de couverture pour les actifs hors ligne au-delà d'un seuil défini.
- Terminaux à convergence OT/IT : Les analyses de sécurité peuvent perturber les systèmes de technologie opérationnelle. Les programmes continus s'adaptent grâce à une surveillance passive, à des modes sans agent ou à des agents en lecture seule lorsque l'environnement OT le permet, à des workflows distincts de détection et de correction pour les actifs OT, ainsi qu'à des politiques d'exclusion explicites assorties de contrôles compensatoires.
- Secteurs réglementés (NIST, PCI DSS, HIPAA) : CVM génère des preuves prêtes pour l'audit, mises en correspondance avec les référentiels de conformité, grâce à une collecte continue de preuves, à une mise en correspondance automatisée des constatations avec les exigences de contrôle, ainsi qu'à une gestion documentée des exceptions tenant compte du contexte réglementaire.
La norme de continuité reste inchangée. L'implémentation s'adapte.
Une fois la question de la complexité de l'environnement abordée, la dernière question qui se pose est de savoir comment le CVM s'intègre à l'ensemble de votre infrastructure de sécurité et informatique.
Intégration de CVM à vos processus existants en matière de sécurité et d'informatique
Un programme continu s'intègre à vos outils de sécurité et informatiques existants, sans les remplacer. Sa valeur dépend de la qualité de l'intégration.
- SIEM/SOAR : Les résultats des analyses de vulnérabilité sont intégrés aux processus opérationnels de sécurité grâce à des alertes automatisées pour les résultats critiques, à un contexte enrichi dans les événements SIEM et à des guides d'intervention SOAR qui déclenchent des actions de correction et de configuration.
- ITSM/gestion des tickets : Les mesures correctives s'intègrent dans le processus de gestion des changements du service informatique. Les exigences relatives au SLA et à la gestion des tickets, telles que décrites dans la section consacrée aux lacunes de coordination, s'appliquent ici.
- Pipelines CI/CD et DevOps : Pour les organisations dont les cycles de mise en production sont rapides, les contrôles de vulnérabilité sont intégrés aux pipelines de déploiement plutôt que d'être exécutés après le déploiement. Dans un modèle DevSecOps, l'approche « shift-left » permet de mettre en évidence les failles de sécurité dès la phase de développement.
- Gestion des correctifs : La mise en œuvre d'un programme continu repose sur un processus de gestion des correctifs efficace, permettant de transformer les constatations en vulnérabilités résolues. Les correctifs du système d'exploitation couvrent l'ensemble le plus large d'actifs ; les correctifs applicatifs concernent les logiciels tiers, les navigateurs et les suites bureautiques, qui représentent une part importante des vulnérabilités exploitées mais sont souvent exclus des processus axés sur le système d'exploitation. En l'absence de processus structurés de correction des vulnérabilités sur ces deux niveaux, les données de détection s'accumulent sans déboucher sur des mesures correctives.
- Gestion des terminaux : La plateforme CVM partage des données avec l'infrastructure d'agents de gestion des terminaux ou fonctionne sur cette même infrastructure, ce qui élimine le recours à des agents d'analyse distincts et permet de corriger les vulnérabilités à partir de la même console que celle qui les a détectées.
Comment Tanium facilite la gestion continue des vulnérabilités
Tout ce qui précède décrit les exigences d'un programme continu. C'est entre le moment où une vulnérabilité est détectée et celui où l'on confirme qu'elle a été corrigée que la plupart des programmes perdent leur continuité, et c'est à ce stade que l'architecture de la plateforme détermine si le programme tient réellement ses promesses.
Les outils de détection permettent d'identifier le problème. La remise en état relève d'une autre équipe, d'un autre outil et d'une autre liste de priorités. C'est ce transfert, qui se répète à travers des milliers de résultats, qui transforme un programme « continu » en un programme périodique.
La plateforme informatique autonome Tanium d' , , comble cette lacune en regroupant la détection, la hiérarchisation, la correction et la vérification au sein d'un seul ensemble de données. Les équipes chargées de la sécurité et de l'informatique travaillent à partir des mêmes données en temps réel issues des terminaux, ce qui élimine le décalage entre le moment où « nous l'avons détecté » et celui où « nous l'avons corrigé ». Lorsqu’une vulnérabilité CVE critique est signalée, Tanium est conçu pour fournir aux équipes une visibilité quasi instantanée sur l’ , la correction et le suivi ( ) dans l’ensemble de l’environnement, afin de leur permettre de passer directement de l’identification à l’application des correctifs.
Sur le plan opérationnel, cela se traduit tout au long du cycle de vie du CVM :
- La visibilité en temps réel sur les actifs remplace les données d'analyse obsolètes : Tanium récupère directement l'état actuel des terminaux, qu'il s'agisse d'appareils gérés, non gérés ou se reconnectant après avoir été hors ligne. Cela signifie que l'inventaire des actifs reflète la situation actuelle, et non celle qui prévalait lors de la dernière fenêtre d'analyse.
- La correction s'effectue là où la détection a lieu : Les résultats sont directement intégrés aux processus de correction et de configuration au sein de la même plateforme. Pas de création manuelle de tickets, pas de retards liés au transfert de prise en charge, pas d'ambiguïté quant à la responsabilité entre la sécurité et l'informatique.
- La vérification en boucle fermée permet de confirmer les corrections apportées, et pas seulement les déploiements : Tanium vérifie la mise en œuvre des correctifs de manière automatisée, sans avoir à programmer une nouvelle analyse. Les données d'état issues des agents permettent de vérifier si la vulnérabilité persiste ; ainsi, une vulnérabilité n'est considérée comme résolue que lorsque la correction est confirmée au niveau du terminal. Pas à la clôture de la vente des billets.
Le déploiement initial des agents sur un parc informatique de grande envergure nécessite une planification, en particulier dans les environnements soumis à un contrôle rigoureux des changements ; toutefois, la charge opérationnelle permanente est compensée par le fait qu'il n'est plus nécessaire de gérer plusieurs outils d'analyse et de correction.
Il ne s'agit pas là de distinctions théoriques. Recovery Centers of America a utilisé Tanium pour détecter 400 000 vulnérabilités sur ses 2 200 terminaux, des vulnérabilités qui n'avaient pas été détectées auparavant. Tanium a ensuite aidé l'organisation à réduire ce nombre de 80 % en un peu plus de deux semaines. RCA a également tiré parti de l'intégration de Tanium avec ServiceNow pour regrouper des outils distincts et intégrer des données en temps réel sur les terminaux dans les workflows de gestion des tickets, de gestion des changements et de gestion des actifs. Consultez l'étude de cas « ».
L'architecture de plateforme unifiée de Tanium résout le problème structurel qui empêche la plupart des programmes de gestion des vulnérabilités (CVM) d'atteindre une véritable continuité : le fossé entre la détection et la correction vérifiée.
En conservant des données en temps réel sur l'état des terminaux et en permettant aux équipes de sécurité et informatiques de détecter, hiérarchiser, corriger et vérifier les problèmes à partir d'un seul et même système, Tanium élimine les retards de coordination et les contraintes liées au changement d'outil qui transforment les programmes « continus » en programmes ponctuels. Les organisations acquièrent la capacité opérationnelle de déterminer en quelques heures si une vulnérabilité CVE récemment divulguée affecte leur environnement et de confirmer de manière automatisée que la correction est terminée, ces deux conditions faisant la différence entre les programmes continus et ceux qui restent au stade des aspirations.
Foire aux questions sur la gestion continue des vulnérabilités
Une véritable continuité passe par la réduction du décalage entre la détection et la correction vérifiée. Les questions suivantes portent sur les lacunes les plus courantes auxquelles les équipes sont confrontées lorsqu'elles évaluent ou mettent en place un programme de gestion de la valeur client (CVM).
Qu'est-ce que la gestion continue des vulnérabilités ?
La gestion continue des vulnérabilités est un processus continu et automatisé qui consiste à détecter, analyser, hiérarchiser et corriger les failles de sécurité au sein de l'infrastructure informatique d'une organisation ; ce processus permet de disposer en temps réel d'une visibilité e sur l'état des actifs et le statut des vulnérabilités, plutôt que de s'appuyer sur des cycles d'analyse périodiques.
Comment la gestion continue des vulnérabilités s'intègre-t-elle aux outils de sécurité existants ?
La gestion continue des vulnérabilités s'intègre aux outils de sécurité et informatiques existants via des plateformes SIEM/SOAR pour l'automatisation des alertes et des workflows de réponse, des systèmes ITSM/de gestion des tickets pour le suivi des mesures correctives, des plateformes de gestion des correctifs pour le déploiement et la vérification automatisés, ainsi qu'une infrastructure de gestion des terminaux permettant d'éliminer les agents redondants et de regrouper la détection et la correction au sein d'un ensemble de données unique.
Comment la gestion continue des vulnérabilités s'intègre-t-elle dans une stratégie de cybersécurité ?
La gestion continue des vulnérabilités constitue la couche opérationnelle qui traduit la stratégie de sécurité en une réduction mesurable des risques, en assurant une visibilité en temps réel sur la surface d'attaque, en hiérarchisant les mesures correctives en fonction de l'exploitabilité et du contexte métier, et en fournissant une évaluation continue des tendances en matière d'exposition qui éclaire les décisions plus générales en matière de gestion des risques.
En quoi la gestion continue des vulnérabilités améliore-t-elle le niveau de sécurité ?
La gestion continue des vulnérabilités renforce le niveau de sécurité en réduisant le délai entre la divulgation d'une vulnérabilité et la correction vérifiée, en éliminant les lacunes de couverture générées par les analyses périodiques et en fournissant à la direction des preuves mesurables de la réduction des risques grâce à des indicateurs tels que le délai moyen de détection ( ), le délai moyen de correction () et les tendances relatives à l'ancienneté des vulnérabilités.
Comment mesurez-vous le succès de la gestion continue des vulnérabilités ?
Le succès se mesure à l'aune de la capacité avérée du programme à réduire l'exposition au fil du temps. Les six indicateurs clés évoqués plus haut dans cet article (pourcentage de couverture de l'analyse, délai moyen de détection, délai moyen de correction, taux de faux positifs, taux d'exceptions et taux de validation des corrections) fournissent des preuves quantifiables. Un programme est efficace lorsque les responsables peuvent observer une courbe de tendance indiquant une réduction des périodes d'exposition, et pas seulement un aperçu ponctuel des tickets en cours.
La gestion continue des vulnérabilités ne constitue pas une catégorie de produits. Il s'agit d'une norme opérationnelle. La question n'est pas de savoir si vos outils d' effectuent des analyses. La question est de savoir si votre programme est capable de déterminer, dès maintenant, quels sont les actifs exposés et si les correctifs apportés hier ont réellement fonctionné. C'est là toute la différence entre « fréquent » et « continu ».
La plateforme unifiée de Tanium offre aux équipes de sécurité et informatiques la visibilité en temps réel et la vérification en boucle fermée nécessaires pour respecter cette norme, éliminant ainsi les lacunes de coordination qui empêchent la plupart des programmes d'atteindre une véritable continuité. Prenez rendez-vous pour une démonstration personnalisée afin de découvrir comment cette solution peut s'adapter à votre environnement :.
