La plupart des programmes de gestion des vulnérabilités se qualifient de « continus ». En fait, peu le sont. La différence compte : un programme qui analyse chaque semaine mais s’appelle en continu crée une fausse confiance, laissant les expositions ouvertes entre les cycles tandis que la direction suppose que la couverture est complète.
La gestion continue des vulnérabilités, ou CVM, est un processus continu et automatisé de découverte, d’analyse, de hiérarchisation et de correction des faiblesses de sécurité dans l’infrastructure informatique d’une organisation. Contrairement aux cycles périodiques d’analyse et de rapport, la CVM maintient une visibilité en temps réel sur l’état des actifs et le statut de vulnérabilité, réduisant ainsi la fenêtre que les pirates informatiques doivent exploiter pour exploiter les failles nouvellement divulguées.
Cet article fournit un cadre de diagnostic pour évaluer si votre programme existant répond à la norme opérationnelle que « continue » implique, couvrant les conditions spécifiques, les mesures et les structures de coordination qui séparent les programmes véritablement continus des programmes fréquents.
Ce que signifie réellement « continu » et pourquoi la plupart des programmes ne sont pas admissibles
La plupart des programmes qui s’appellent « continus » s’exécutent toujours sur des cycles d’analyse hebdomadaires ou mensuels. Ils hiérarchisent par lots, créent des tickets manuellement et supposent que la remédiation a été effectuée sans la vérifier. Pendant ce temps, la surface d’attaque continue de changer : de nouveaux actifs démarrent, les configurations dérivent et les CVE nouvellement divulgués créent des fenêtres d’exposition que les cycles d’analyse hebdomadaires ne peuvent pas fermer.
Les programmes périodiques planifient les analyses, la hiérarchisation des lots et la génération manuelle de tickets. Les programmes continus maintiennent une sensibilisation en temps réel à l’état, déclenchent la hiérarchisation lorsque les conditions changent et vérifient la remédiation grâce à des vérifications en boucle fermée.
Un programme véritablement continu répond à tous les critères suivants :
- Les nouveaux actifs sont détectés et inventoriés en quelques heures, et non en quelques jours
- Les vulnérabilités nouvellement divulguées sont évaluées par rapport à l’inventaire complet des actifs dans un SLA défini
- Le statut de remédiation est vérifié par programmation, non supposé
La plupart des programmes ne disposent pas d’au moins l’une de ces propriétés, et la raison est généralement qu’ils se trouvent sur le spectre de maturité de surveillance.
Trois niveaux de continuité de la surveillance : périodique, haute fréquence et temps réel
Comprendre où se situe votre programme sur le spectre de la surveillance continue des vulnérabilités aide à clarifier ce qui « continue » coûte réellement et les lacunes qui subsistent.
Niveau 1 : analyse périodique. Les analyses planifiées s’exécutent chaque semaine, chaque mois ou chaque trimestre. La latence de détection des vulnérabilités est mesurée en jours ou en semaines. Il existe des écarts de couverture entre les cycles. Cette approche fonctionne pour les environnements stables à faible changement, mais manque les vulnérabilités qui émergent en milieu de cycle.
Niveau 2 : analyse haute fréquence. Les cycles d’analyse quotidiens ou quasi quotidiens réduisent la latence de détection à heures. La couverture s’améliore pour les environnements dynamiques, mais les actifs éphémères tels que les conteneurs et les instances cloud à échelle automatique (y compris les charges de travail exécutées dans des clusters Kubernetes qui peuvent tourner et se terminer dans un seul intervalle d’analyse) peuvent toujours exister entre les fenêtres d’analyse et passer inaperçus.
Niveau 3 : surveillance d’état en temps réel basée sur les agents. Les agents persistants signalent l’état et la configuration des actifs en continu. La latence de détection passe à minutes. Les actifs éphémères et de reconnexion hors ligne sont couverts. Le compromis est le déploiement des agents et la gestion des frais généraux.
| Niveau | Latence de détection | Couverture des actifs | Meilleur ajustement |
|---|---|---|---|
| Périodique | Jours à semaines | Écarts entre les cycles | Environnements stables et à faible changement |
| Haute fréquence | Heures | Manque les actifs éphémères | Infrastructure dynamique mais prévisible |
| Temps réel | Minutes | Couvre les actifs hors ligne/éphémères | Environnements volumineux, distribués ou en évolution rapide |
La plupart des programmes d’entreprise fonctionnent au niveau 1 ou 2 et supposent qu’ils sont « continus ». L’architecture à agent unique de Tanium fournit des données d’état en temps réel qui éliminent l’écart de latence inhérent à l’ analyse planifiée des vulnérabilités. La question n’est pas de savoir quel niveau est « le meilleur ». C’est le niveau qui correspond au profil de risque de votre environnement et à la vitesse de changement.
Le niveau de surveillance détermine la vitesse à laquelle vous trouvez les vulnérabilités. Ce qui se passe ensuite détermine si les trouver est important.
Là où les programmes CVM d’entreprise se décomposent : l’écart de coordination IT/SecOps
La détection sans remédiation n’est qu’une sensibilisation coûteuse. Le seul plus grand échec de continuité dans le CVM d’entreprise n’est pas un problème technologique. Il s’agit d’un problème de coordination qui empêche les équipes de corriger les vulnérabilités détectées à la vitesse requise par le programme. Cet écart de coordination a de réelles conséquences : les recherches montrent constamment que de nombreuses violations de données remontent non pas à des vulnérabilités non détectées, mais à des vulnérabilités connues qui n’ont pas été corrigées parce que personne n’a détenu le transfert entre la sécurité et l’informatique.
Les équipes de sécurité détectent les vulnérabilités. La remédiation dépend des équipes d’opérations informatiques ayant différentes priorités, différents SLA et différents processus de contrôle des modifications. L’écart entre « nous l’avons trouvé » et « nous l’avons corrigé » est l’endroit où vit l’exposition.
Échecs d’intégration d’émission. Lorsque les résultats de vulnérabilité nécessitent la création manuelle de tickets, les retards mesurés en jours sont courants. La billetterie intégrée semble différente : les résultats génèrent automatiquement des tickets avec la gravité, le contexte des actifs et les conseils de remédiation joints. Les transferts manuels introduisent des frictions qui se répercutent sur des milliers de résultats.
Désalignement SLA. La sécurité définit la criticité par CVSS ou score de risque. Le service informatique définit la priorité en fonction de la disponibilité de la fenêtre de changement et de l’impact commercial. Sans niveaux SLA partagés, les vulnérabilités critiques se trouvent dans les files d’attente tandis que les équipes se disputent sur la planification.
Une structure SLA pratique peut ressembler à ceci :
- Niveau 1 (critique, activement exploité) : SLA de remédiation 24 heures sur 24
- Niveau 2 (élevé, exploit disponible) : SLA de 7 jours (atteignable à grande échelle avec des correctifs automatisés ; ajuster en fonction de la complexité de l’environnement)
- Niveau 3 (moyen/faible) : fenêtre de maintenance planifiée ou acceptée par le risque
L’ambiguïté de la propriété. Lorsque personne n’est propriétaire du résultat de remédiation de bout en bout, les vulnérabilités vieillissent dans les files d’attente de tickets. Un processus de remédiation clairement défini répond à trois questions : Qui est propriétaire du ticket ? Qui est responsable de la vérification ? Qui est propriétaire de l’exception si la remédiation est différée ?
Alors, à quoi ressemble réellement un programme véritablement continu ? La section suivante le décompose en cinq conditions testables.
Les cinq conditions qu’un programme véritablement continu remplit
Considérez les éléments suivants comme une liste de contrôle, et non comme un cycle de vie. Chaque condition est remplie ou non. Le crédit partiel ne réduit pas l’exposition.
1. Inventaire complet et en temps réel des actifs
Le programme maintient un inventaire à l’état actuel qui tient compte des actifs éphémères, distants et hors ligne. Ce n’est pas une CMDB qui est à la traîne par rapport à la réalité de plusieurs jours ou semaines.
Test : pouvez-vous confirmer dans l’heure si un CVE critique nouvellement divulgué affecte un actif dans votre environnement ? Si la réponse est « nous devrons d’abord exécuter une analyse », vous avez un écart de continuité.
2. Détection axée sur les événements
De nouvelles vulnérabilités déclenchent des workflows de détection immédiatement après la divulgation, et non à la fenêtre d’analyse suivante. Cela nécessite une intégration active avec les flux de renseignements sur les menaces et les avis de sécurité des fournisseurs, y compris les mises à jour KEV CISA, les publications NVD et les bulletins spécifiques aux fournisseurs tels que Microsoft Patch Tuesday et les avis de distribution Linux, afin que les événements de divulgation initient automatiquement l’évaluation des actifs plutôt que d’attendre une analyse planifiée.
Test : lorsqu’un CVE critique est publié, combien de temps avant que votre programme évalue chaque actif par rapport à celui-ci ? Les heures sont continues. Les jours sont fréquents. Les semaines sont périodiques.
3. Hiérarchisation contextuelle intégrée au workflow
La hiérarchisation utilise la criticité des actifs, les signaux d’exploitabilité tels que EPSS et CISA KEV, et les renseignements sur les menaces (y compris les menaces émergentes qui peuvent ne pas encore présenter des scores CVSS élevés, mais qui sont activement en cours d’armement). Exploit Prediction Scoring System (EPSS) estime la probabilité qu’une vulnérabilité soit exploitée à l’état sauvage dans les 30 jours, fournissant un signal prospectif que la gravité CVSS ne peut pas capturer à elle seule. Il s’agit du domaine de la gestion des vulnérabilités basée sur les risques, qui couvre la méthodologie.
4. Correction avec vérification en boucle fermée
Chaque action de remédiation est vérifiée par programme. La vulnérabilité n’est pas marquée comme « résolue » tant qu’une vérification de suivi n’a pas confirmé la correction. La remédiation automatisée des vulnérabilités couvre les approches de mise en œuvre.
5. Mesures et rapports continus
Le programme suit ses propres mesures de performance et les rapporte aux parties prenantes à une cadence définie. Pas seulement lorsque les auditeurs le demandent. Si vous ne pouvez pas répondre « Quel est notre temps moyen pour remédier aux vulnérabilités critiques ? » sans générer de rapport personnalisé, le programme génère des rapports à la demande, sans effectuer de mesure continue.
Une défaillance sur une condition unique crée une exposition. Un programme avec une détection parfaite, mais aucune vérification n’est une activité de reporting, et non des résultats.
Sur les cinq conditions, la vérification est la plus souvent ignorée entièrement. Voyons pourquoi cela est important.
Validation : l’étape CVM que la plupart des programmes ignorent
La plupart des équipes marquent les vulnérabilités comme « résolues » lorsqu’un correctif se déploie, et non lorsque l’exposition est confirmée comme fermée. Cet écart entre « nous avons repoussé le correctif » et « le correctif a réellement fonctionné » est la source d’une fausse confiance.
Avant remédiation
Confirmation de la pré-remédiation
Avant d’attribuer une vulnérabilité pour la remédiation, confirmez que le résultat du scanner représente une exposition réelle et exploitable. Il ne s’agit pas d’un faux positif ou d’un artefact de configuration. Cette étape détecte également les erreurs de configuration que les scanners présentent comme des vulnérabilités : des problèmes qui peuvent nécessiter un changement de configuration plutôt qu’un correctif, et qui sont acheminés de manière incorrecte lorsque le triage pré-remédiation est ignoré. Ignorer cette étape gaspille les cycles informatiques et érode la confiance dans le programme VM au fil du temps.
Après le déploiement du correctif
Vérification post-remédiation
Après le déploiement d’un correctif de sécurité ou d’un changement de configuration, vérifiez programmatiquement que la vulnérabilité est réellement fermée. Une nouvelle analyse ou une vérification d’état basée sur un agent confirme que la condition vulnérable n’existe plus sur l’actif. « Le ticket est fermé » n’est pas une vérification.
Pour les actifs de grande valeur
Validation contradictoire
Pour les actifs de grande valeur ou les étapes de remédiation critiques, les tests de pénétration fournissent une couche de validation contradictoire que la vérification automatisée ne peut pas reproduire. Les réanalyses programmatiques confirment qu’une condition vulnérable spécifique est fermée ; un test ciblé va plus loin. Des vérifications automatisées confirment la fermeture d’une condition. Ils ne peuvent pas confirmer que l’exposition a disparu.
Lorsque la remédiation n’est pas possible
Gestion des exceptions
Pour les vulnérabilités qui ne peuvent pas être corrigées, comme les systèmes existants ou les applications critiques pour l’entreprise avec des gels de modifications, définissez un processus d’exception formel. Documentez l’acceptation des risques, les contrôles compensatoires, la fréquence d’examen et les dates d’expiration. Les exceptions sans dates d’expiration deviennent une exposition permanente.
Un programme CVM qui ne peut pas démontrer l’efficacité de la remédiation consiste à mesurer l’occupation, et non la sécurité.
La vérification répond si les correctifs individuels ont fonctionné. Les mesures indiquent si le programme lui-même fonctionne. Voici comment faire la différence.
Comment mesurer si votre programme CVM fonctionne
Les mesures sont le seul moyen de distinguer un programme véritablement continu d’un programme qui est simplement fréquent. Suivez les éléments suivants, signalez-les régulièrement et utilisez-les pour favoriser l’amélioration. Pris ensemble, ces indicateurs donnent au leadership une vue mesurable de la posture de sécurité de l’organisation : non seulement un aperçu des tickets ouverts, mais une ligne de tendance montrant si le programme réduit réellement les cyber-risques au fil du temps.
| Métrique | Ce qu’il mesure | Référence saine |
|---|---|---|
| Pourcentage de couverture d’analyse | Proportion d’actifs connus sous surveillance active | Près de 100 %, avec des exceptions documentées |
| Délai moyen de détection (MTTD) | Heures entre la publication du CVE et la confirmation de l’impact | Heures pour les CVE critiques, pas les jours |
| Temps moyen de remédiation (MTTR) | Délai entre la détection et la clôture vérifiée, par gravité | Dans les niveaux SLA définis |
| Taux de faux positifs | Pourcentage de résultats qui ne sont pas exploitables | Déclin au fil du temps |
| Taux d’exception | Pourcentage de résultats acceptés par le risque par rapport à corrigés | Stable ou en déclin, tous documentés |
| Taux de validation des mesures correctives | Pourcentage de résultats « résolus » vérifiés par programme | Près de 100 % pour critique/élevé |
Le vieillissement des vulnérabilités est une septième mesure facultative : combien de temps les vulnérabilités restent-elles ouvertes dans l’environnement au fil du temps ? Une distribution saine biaise vers une clôture rapide, avec un âge acceptable maximum défini pour chaque niveau de gravité et des attentes claires en matière de délais de remédiation.
Si la direction ne voit les données de vulnérabilité que lorsque la conformité le demande, le programme génère des rapports à la demande, ne mesurant pas de manière continue ou proactive les risques.
Les mesures vous indiquent si le programme fonctionne. Ils ne tiennent pas compte des réalités opérationnelles qui rendent la mise en œuvre plus difficile. La manière dont un programme répond à ces exigences change lorsque l’environnement lui-même est complexe et distribué.
CVM dans des environnements complexes et réglementés
Les environnements complexes n’exonèrent pas un programme des conditions de continuité définies précédemment. Ils ajoutent des contraintes opérationnelles que le programme prend en charge.
- endpoints distribués et hors ligne : les agents distants peuvent fonctionner connectés par intermittence. Les programmes continus gèrent cela via la synchronisation des états lors de la reconnexion, des actions de remédiation en file d’attente et du suivi des écarts de couverture pour les actifs hors ligne au-delà d’un seuil défini.
- Endpoints convergents OT/IT : l’analyse peut perturber les systèmes technologiques opérationnels. Les programmes continus s’adaptent avec une surveillance passive, des modes d’agent sans agent ou en lecture seule où l’environnement OT le permet, des workflows de détection et de remédiation distincts pour les actifs OT, et des politiques d’exclusion explicites avec des contrôles compensatoires.
- Secteurs réglementés (NIST, PCI DSS, HIPAA) : CVM produit des preuves prêtes pour l’audit cartographiées aux cadres de conformité grâce à une collecte continue de preuves, une cartographie automatisée des résultats pour contrôler les exigences et une gestion documentée des exceptions dans un contexte réglementaire.
La norme de continuité ne change pas. La mise en œuvre s’adapte.
Avec la complexité de l’environnement traitée, la dernière question est la manière dont CVM se connecte à tout le reste de votre infrastructure informatique et de sécurité.
Connecter CVM à vos workflows informatiques et de sécurité existants
Un programme continu est lié à vos outils informatiques et de sécurité existants plutôt que de les remplacer. Sa valeur dépend de la qualité de l’intégration.
- SIEM/SOAR : les résultats de vulnérabilité circulent dans les workflows des opérations de sécurité grâce à des alertes automatisées pour les résultats critiques, un contexte enrichi dans les événements SIEM et des playbooks SOAR qui déclenchent des actions de correction et de configuration.
- ITSM/émission : les actions de remédiation sont intégrées au processus de gestion des modifications du service informatique. Les exigences de SLA et d’émission de la section des écarts de coordination s’appliquent ici.
- Pipelines CI/CD et DevOps : pour les organisations avec des cycles de publication rapides, les contrôles de vulnérabilité s’intègrent dans les pipelines de déploiement plutôt que d’exécuter le post-déploiement. Dans un modèle DevSecOps, l’analyse à gauche permet de détecter les résultats de sécurité pendant le développement.
- Gestion des correctifs : un programme continu dépend d’un workflow de gestion des correctifs fonctionnel pour traduire les résultats en expositions fermées. L’application de correctifs sur le système d’exploitation couvre l’empreinte d’actifs la plus large ; l’application de correctifs s’adresse aux logiciels, navigateurs et suites de productivité tiers qui représentent une part significative des vulnérabilités exploitées, mais sont fréquemment exclus des workflows axés sur le système d’exploitation. Sans processus d’application de correctifs structurés sur les deux couches, les données de détection s’accumulent sans produire de résultats de remédiation.
- Gestion des endpoints : la plateforme CVM partage des données avec la même infrastructure d’agents que la gestion des endpoints ou fonctionne sur celle-ci, éliminant ainsi les agents d’analyse distincts et permettant la remédiation à partir de la même console qui a détecté la vulnérabilité.
Comment Tanium prend en charge la gestion continue des vulnérabilités
Tout ce qui précède décrit ce qu’un programme continu exige. L’écart entre la détection d’une vulnérabilité et la confirmation de sa résolution est l’endroit où la plupart des programmes perdent de la continuité, et où l’architecture de la plateforme détermine si le programme fournit réellement.
Les outils de détection détectent le problème. La remédiation dépend d’une équipe différente, d’un outil différent et d’une liste de priorités différente. Ce transfert, répété sur des milliers de résultats, est ce qui transforme un programme « continu » en programme périodique.
La Tanium Autonomous IT Platform comble cet écart en conservant la détection, la hiérarchisation, la remédiation et la vérification sur un seul jeu de données. Les équipes de sécurité et informatiques travaillent à partir des mêmes données d’endpoint en temps réel, ce qui élimine le décalage entre « nous l’avons trouvée » et « nous l’avons corrigée ». Lorsqu’un CVE critique chute, Tanium est conçu pour donner aux équipes une visibilité quasi instantanée sur les mesures correctives dans l’ensemble de l’environnement afin de les aider à passer directement de l’identification à l’application de correctifs.
Opérationnellement, cela se joue tout au long du cycle de vie du CVM :
- La connaissance des actifs en temps réel remplace les données d’analyse obsolètes : Tanium extrait l’état actuel directement des endpoints, couvrant les appareils gérés, non gérés et de reconnexion hors ligne. Cela signifie que l’inventaire des actifs reflète ce qui existe actuellement, et non ce qui existait à la dernière fenêtre d’analyse.
- La remédiation se produit là où la détection se produit : les résultats circulent directement dans les workflows d’application de correctifs et de configuration au sein de la même plateforme. Aucune création manuelle de ticket, aucun retard de transfert, aucune ambiguïté de propriété entre la sécurité et l’informatique.
- La vérification en boucle fermée confirme les correctifs, et pas seulement les déploiements : Tanium vérifie la remédiation par programme sans planifier une réanalyse. Les données d’état basées sur l’agent confirment si la condition vulnérable persiste, de sorte qu’une vulnérabilité est marquée comme résolue uniquement lorsque la correction est confirmée au niveau du endpoint. Pas lorsque le ticket se ferme.
Le déploiement initial des agents sur une grande flotte nécessite une planification, en particulier pour les environnements avec un contrôle strict des modifications, mais les frais opérationnels continus sont compensés en éliminant la nécessité de maintenir plusieurs outils d’analyse et de remédiation.
Ce ne sont pas des distinctions théoriques. Recovery Centers of America a utilisé Tanium pour découvrir 400 000 vulnérabilités sur ses 2 200 endpoints, 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 à ServiceNow pour consolider des outils distincts et alimenter en temps réel les données des endpoints dans les workflows de billetterie, de gestion des modifications et de gestion des actifs. Lisez 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 CVM d’atteindre une véritable continuité : l’écart entre la détection et la remédiation vérifiée.
En maintenant les données d’état des endpoints en temps réel et en permettant aux équipes de sécurité et informatiques de détecter, hiérarchiser, corriger et vérifier à partir d’un seul système, Tanium élimine les retards de coordination et les frais généraux de commutation d’outils qui transforment les programmes « continus » en programmes fréquents. Les organisations acquièrent la capacité opérationnelle de répondre en quelques heures si un CVE nouvellement divulgué affecte leur environnement et de confirmer programmatiquement lorsque la remédiation est terminée, les deux conditions qui séparent les programmes continus des programmes ambitieux.
Foire aux questions sur la gestion continue des vulnérabilités
La véritable continuité dépend de la réduction de l’écart entre la détection et la remédiation vérifiée. Les questions suivantes abordent les lacunes les plus courantes que les équipes rencontrent lors de l’évaluation ou de l’élaboration d’un programme 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é de découverte, d’analyse, de hiérarchisation et de remédiation des faiblesses de sécurité dans l’infrastructure informatique d’une organisation qui maintient une visibilité en temps réel 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 informatiques et de sécurité existants via des plateformes SIEM/SOAR pour les workflows automatisés d’alerte et de réponse, des systèmes ITSM/de billetterie pour le suivi des remédiations, des plateformes de gestion des correctifs pour le déploiement et la vérification automatisés, et une infrastructure de gestion des endpoints pour éliminer les agents redondants et consolider la détection et la remédiation sur un seul jeu de données.
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 sert de couche opérationnelle qui traduit la stratégie de sécurité en une réduction mesurable des risques en maintenant une visibilité en temps réel sur la surface d’attaque, en hiérarchisant la remédiation en fonction de l’exploitabilité et du contexte commercial, et en fournissant une mesure continue des tendances d’exposition qui éclairent les décisions plus larges de gestion des risques.
Comment la gestion continue des vulnérabilités améliore-t-elle la posture de sécurité ?
La gestion continue des vulnérabilités améliore la posture de sécurité en réduisant la fenêtre entre la divulgation des vulnérabilités et la remédiation vérifiée, en éliminant les lacunes de couverture que l’analyse périodique crée et en fournissant au leadership des preuves mesurables de réduction des risques grâce à des mesures telles que le temps moyen de détection, le temps moyen de remédiation et les tendances de vieillissement des vulnérabilités.
Comment mesurez-vous le succès de la gestion continue des vulnérabilités ?
La réussite est mesurée par la réduction manifeste de l’exposition au fil du temps. Les six mesures de base couvertes précédemment dans cet article (pourcentage de couverture d’analyse, temps moyen de détection, temps moyen de remédiation, taux de faux positifs, taux d’exception et taux de validation de remédiation) fournissent les preuves mesurables. Un programme fonctionne lorsque la direction peut voir une ligne de tendance montrant la réduction des fenêtres d’exposition, et pas seulement un instantané des tickets ouverts.
La gestion continue des vulnérabilités n’est pas une catégorie de produit. C’est une norme opérationnelle. La question n’est pas de savoir si vos outils exécutent des analyses. Il s’agit de savoir si votre programme peut répondre, en ce moment, aux actifs exposés et si les correctifs d’hier ont réellement fonctionné. C’est 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 répondre à cette norme, éliminant ainsi les lacunes de coordination qui empêchent la plupart des programmes d’atteindre une véritable continuité. Planifiez une démo personnalisée pour voir comment elle peut fonctionner pour votre environnement.
