La plupart des programmes de gestion des vulnérabilités qui se prétendent automatisés ne le sont pas. Ils ont accéléré certaines étapes individuelles, telles que la numérisation et peut-être la création de tickets, sans toutefois les intégrer dans un flux de travail permettant de clôturer les dossiers sans intervention humaine. C'est dans l'écart entre le moment où « l'automatisation s'est déclenchée » et celui où « l'exposition a effectivement été comblée » que les programmes échouent.
Cet article explique ce qui distingue un programme de gestion des vulnérabilités véritablement automatisé d'un programme qui se contente de générer de l'activité plus rapidement, notamment le cadre de gouvernance, l'architecture des flux de travail et les indicateurs permettant de déterminer si l'automatisation produit des résultats.
Qu'est-ce qui distingue un programme automatisé de gestion des vulnérabilités d'un programme standard ?
L'automatisation de la gestion des vulnérabilités permet d'identifier, d'évaluer, de hiérarchiser et de corriger en continu les failles de sécurité, avec une intervention humaine minimale. Elle remplace les cycles d'analyse sporadiques par une détection en temps réel, une hiérarchisation automatisée s'appuyant sur les renseignements sur les menaces et des flux de travail coordonnés.
C'est la définition type. En réalité, la plupart des programmes qui se qualifient d'« automatisés » ne sont pas à la hauteur. Ils ont automatisé l'analyse, voire la création de tickets, mais les étapes entre la sortie des résultats du scanner et la résolution d'une vulnérabilité restent encore manuelles, notamment l'enrichissement des résultats, la recherche des responsables des actifs et la coordination entre les équipes. Qualifier cela d'« automatisation » revient à exagérer les capacités réelles de cet outil.
Et les enjeux sont bien réels. Les retards non rattrapés peuvent accroître considérablement le risque de violation de sécurité, car les pirates exploitent régulièrement des vulnérabilités connues que les organisations n'ont tout simplement pas encore eu le temps de corriger.
La différence entre un programme standard de gestion des vulnérabilités de type « » et un programme véritablement automatisé se résume à trois éléments : la détection continue (et non des analyses périodiques), la hiérarchisation automatisée (et non le simple recours à des étiquettes de gravité) et la correction orchestrée avec validation (et non « correctif déployé, ticket clôturé »).
Trois types de défaillances reviennent régulièrement dans les programmes qui misent sur l'automatisation sans cadre de gouvernance :
- Automatiser la détection sans automatiser la hiérarchisation : Les analyses continues génèrent des milliers de résultats. Sans système de hiérarchisation automatisé, les résultats s'accumulent plus vite que les analystes ne parviennent à les trier. La file d'attente s'allonge, et la fatigue liée aux alertes s'installe.
- Automatisation des corrections sans gouvernance : Application automatisée des correctifs : cela semble efficace jusqu'à ce qu'une mise à jour non testée provoque une panne du système de production. Une automatisation mise en œuvre sans déploiement progressif comporte un risque lié au changement qui peut dépasser le risque cyber que vous cherchez à réduire.
- Automatisation des étapes sans les relier entre elles : Discovery alimente une console de scan, tandis que la hiérarchisation s'effectue dans un tableur. Les tickets de correction sont gérés dans un outil de gestion des services informatiques (ITSM). Chaque étape est « automatisée » de manière isolée, mais les transferts entre elles se font manuellement.
Il en résulte une surface d'attaque de plus en plus vaste dont aucune équipe ne dispose d'une visibilité complète, et que l'automatisation, sous sa forme fragmentée, ne contribue en rien à réduire.
Un cadre d'automatisation à plusieurs niveaux
Tous les éléments d'un programme de gestion des vulnérabilités ne présentent pas le même profil de risque. Certaines tâches peuvent être entièrement automatisées en toute sécurité. D'autres nécessitent une vérification humaine. Les critères qui déterminent le périmètre comprennent la criticité des actifs, le risque lié aux changements et le niveau de fiabilité des données.
Automatisation de la recherche
L'analyse continue constitue la base de la découverte des actifs. La décision en matière de gouvernance ne porte pas sur l'opportunité d'automatiser la découverte, mais sur la manière d'en définir la portée. Quelles sont les catégories d'actifs concernées ? Quels réseaux ? Quelle fréquence est la plus appropriée pour les cibles sans agent ?
Un inventaire complet et à jour des ressources d' est une condition préalable à une automatisation efficace de la recherche : vous ne pouvez pas analyser ce dont vous ignorez l'existence.
L'automatisation de la recherche est un minimum indispensable. Si vous effectuez encore des analyses mensuelles, vous n'êtes pas prêt pour la gestion automatisée des vulnérabilités.
Automatisation de la hiérarchisation des priorités
La hiérarchisation automatisée nécessite des données d'entrée lisibles par machine. Le système intègre au minimum les scores du système de notation des prédictions d'exploitation (EPSS), qui estiment la probabilité qu'une vulnérabilité soit exploitée en conditions réelles dans un délai de 30 jours, le catalogue des vulnérabilités connues pour avoir été exploitées (KEV) de la CISA, ainsi que les données relatives à la criticité des actifs.
Si le score du système commun d'évaluation des vulnérabilités (CVSS) constitue une référence utile en matière de gravité, le fait de s'y fier uniquement, sans y associer les données issues de l'EPSS, du KEV et de la criticité des actifs, aboutit à une liste de priorités qui ne reflète pas la vulnérabilité réelle à l'exploitation. De nombreuses plateformes extraient également les informations relatives aux vulnérabilités directement de la NVD (National Vulnerability Database) afin de garantir que les métadonnées CVE restent à jour sans nécessiter de mises à jour manuelles. Si le système oblige un analyste à enrichir manuellement ses conclusions à l'aide des informations sur les menaces fournies par , cela constitue un goulot d'étranglement. L'intérêt de la hiérarchisation automatisée réside précisément dans le fait de mettre en évidence les vulnérabilités importantes sans que les analystes aient à examiner chaque résultat.
La gestion des vulnérabilités basée sur les risques, souvent abrégée en RVM, explique comment les données d'entrée sont combinées pour obtenir un score de risque. En matière d'automatisation, la question est la suivante : le système est-il capable d'intégrer automatiquement des sources de données et d'appliquer une logique de hiérarchisation sans intervention manuelle ?
Automatisation des mesures correctives
La correction des vulnérabilités entraîne un risque lié au changement, ce qui rend la gouvernance essentielle.
Si l'automatisation des corrections ( ) peut améliorer la rapidité d'intervention, une automatisation mal définie peut entraîner des interruptions de service ou déstabiliser les systèmes de production. L'essentiel est de déterminer dans quels cas l'automatisation est appropriée et dans quels cas une validation humaine est nécessaire. Dans la pratique, cette limite est déterminée par le niveau de criticité des actifs, le degré de fiabilité des correctifs et l'impact potentiel d'une défaillance.
- Automatisez entièrement la gestion des actifs à faible niveau de criticité grâce à des correctifs hautement fiables
- Exiger une autorisation pour les systèmes de production, les ressources exposées sur Internet ou les correctifs présentant des scores de confiance faibles
- Utilisez , une solution de déploiement progressif en anneau , pour mettre en place des déploiements par étapes et détecter les problèmes avant qu'ils n'atteignent les systèmes critiques.
La possibilité de revenir en arrière est une condition préalable à tout niveau d'automatisation. Si un correctif entraîne une instabilité, le système doit annuler automatiquement la modification ou déclencher une intervention pendant la fenêtre de maintenance définie.
Automatisation de la validation
De nombreux programmes considèrent la validation comme une simple case à cocher à la fin du cycle de vie. Il s'agit en réalité d'une fonctionnalité automatisée distincte qui permet de vérifier si la correction a fonctionné.
| Domaine | Automatiser entièrement | Intervention humaine | Critères de délimitation |
|---|---|---|---|
| Découverte | Une analyse continue de l'ensemble des classes d'actifs | Décisions relatives au champ d'application pour les réseaux sensibles | Sensibilité du réseau, exigences de conformité (par exemple, HIPAA, PCI DSS) |
| Hiérarchisation des priorités | EPSS/KEV/collecte et évaluation de la criticité | Gestion des exceptions en cas de résultats contestés | Fiabilité des données, litiges liés au contexte commercial |
| Remédiation | Actifs à faible niveau de criticité, correctifs hautement fiables | Systèmes de production, ressources connectées à Internet | Criticité des actifs, fiabilité des correctifs |
| Validation | Nouvelle analyse automatisée et vérification de l'état | Enquête sur un échec de validation | Taux d'échec de validation, complexité des exceptions |
Ce cadre n'est pas figé. À mesure que la confiance dans l'automatisation s'accroît et que les taux de faux positifs diminuent, les tâches peuvent passer d'un mode « human-in-the-loop » à un mode entièrement automatisé.
Les liens entre l'identification, la hiérarchisation et la correction
Le cadre à plusieurs niveaux définit ce qu'il convient d'automatiser à chaque étape, mais la gouvernance au sein de chacune de ces étapes ne résout pas le problème qui se pose entre elles.
La gestion automatisée des vulnérabilités échoue souvent au niveau des transferts de responsabilité. Chaque étape peut fonctionner efficacement de manière isolée, mais lorsque les données ne transmettent pas de contexte d'une étape à l'autre, le flux de travail est perturbé. Cela est particulièrement vrai dans les environnements informatiques complexes, où la propriété des ressources, la segmentation du réseau et les dépendances entre les systèmes varient considérablement d'une équipe à l'autre.
Les liens les plus importants se situent à deux étapes clés du processus de travail.
De la découverte à la hiérarchisation
Les scanners permettent d'obtenir des résultats. Les moteurs de hiérarchisation les utilisent. Ce qui importe, c'est ce qui circule entre les deux systèmes.
Ce qui ne fonctionne pas :
- Fichier numérisé brut, hors contexte métier
- Enrichissement manuel des résultats avant la hiérarchisation
- Données manquantes concernant la criticité, la propriété et l'exposition des actifs
Si les résultats sont fournis sous forme de données brutes issues de l'analyse (identifiant CVE, score de gravité, hôte concerné), le moteur de hiérarchisation ne dispose pas des informations nécessaires pour évaluer le risque réel. La criticité des actifs, la fonction métier, l'emplacement sur le réseau et les contrôles compensatoires influencent tous les décisions relatives à la hiérarchisation des priorités. Lorsque ce contexte nécessite un enrichissement manuel, cela crée un goulot d'étranglement. La différence réside dans le fait de savoir si ce contexte est automatiquement associé au résultat ou s'il doit être ajouté manuellement.
Le workflow aboutit lorsque les résultats de la découverte incluent par défaut le contexte des ressources. Le scanner identifie ou interroge le niveau de criticité, le rôle métier et l'exposition réseau de l'actif, et ces informations contextuelles sont transmises avec le résultat au moteur de hiérarchisation.
Ce qui fonctionne :
- Le contexte de l'élément accompagne chaque résultat
- La criticité, la fonction métier et l'exposition du réseau sont prises en compte automatiquement
- Les contrôles compensatoires sont pris en compte dans l'évaluation des risques
Les mesures de compensation, telles que la segmentation du réseau, les règles WAF ou la couverture de détection au niveau des terminaux, devraient réduire le score de risque effectif lorsqu'elles limitent de manière avérée la vulnérabilité aux exploits. Les moteurs de hiérarchisation qui ignorent ces contrôles attribuent un niveau de gravité excessif à des problèmes qui sont déjà partiellement résolus.
Hiérarchisation des mesures correctives
Les constatations classées par ordre de priorité deviennent des mesures correctives. Si les tickets ne contiennent qu'un identifiant CVE et une mention de gravité, l'équipe chargée de la correction ne dispose pas des informations nécessaires pour intervenir. Le processus est bloqué lorsque les tickets ne fournissent pas le contexte nécessaire à la prise de mesures.
Ce qui ne fonctionne pas :
- Tickets ne comportant que des notes de gravité et des identifiants CVE
- Non-respect des délais prévus par le SLA et informations relatives à la propriété
- Absence de recommandations en matière d'assainissement ou de contexte de hiérarchisation
La mise en place d'un flux de travail efficace dépend de la capacité des tickets à fournir suffisamment d'informations contextuelles pour permettre une intervention immédiate.
Ce qui fonctionne :
- Les tickets indiquent le propriétaire de l'actif, la date limite prévue par le SLA et le niveau de risque
- Les consignes de remédiation sont jointes lors de la création
- Les signaux d'alerte tels que l'EPSS et le KEV sont pris en compte jusqu'à l'exécution
La connexion fonctionne lorsque les tickets sont entièrement complétés au moment de leur création. Les données relatives à la propriété des actifs déterminent l'acheminement. Le niveau de risque détermine le degré d'urgence. Les recommandations en matière d'assainissement permettent de lever les ambiguïtés. Le ticket est valable dès sa création.
Les signaux de menace , tels que les flux de données EPSS et KEV, doivent être pris en compte tout au long du processus. Si une vulnérabilité est signalée comme étant activement exploitée, cette mention est reprise dans la tâche de correction, de sorte que l'équipe voit apparaître la mention « activement exploitée », et pas seulement « gravité critique ».
La couche de coordination entre l'informatique et les opérations de sécurité (SecOps)
L'automatisation se heurte souvent à des barrières organisationnelles entre les informatiques et de sécurité, les équipes de sécurité étant chargées de l'identification et de la hiérarchisation des problèmes, tandis que les opérations informatiques se chargent de la mise en œuvre des mesures correctives. Si le transfert d'informations entre eux se fait par le biais d'une feuille de calcul ou d'un e-mail, l'automatisation n'a pas résolu le problème de coordination.
Limites des propriétés
Un modèle de responsabilité clair définit qui est responsable de chaque étape. Le service de sécurité est responsable de la configuration de la détection, de la logique de hiérarchisation et de la définition des niveaux de risque. Le service des opérations informatiques est chargé de la mise en œuvre des mesures correctives, de la gestion des changements et de la planification des déploiements. Les deux parties partagent la responsabilité de la validation et du respect du contrat de niveau de service (SLA).
En l'absence d'une attribution explicite des responsabilités, les résultats s'accumulent dans une file d'attente dont aucune des deux équipes ne se sent responsable. Le service de sécurité déclare : « Nous l'avons identifié. » Le service informatique déclare : « Nous ne savions pas que c'était urgent. » La vulnérabilité persiste.
Intégration ITSM
La solution « ServiceNow Vulnerability Response » (ou toute intégration ITSM équivalente) automatise l'acheminement des workflows et l'attribution des responsabilités en fonction du contexte des actifs. Lorsqu'un incident classé par ordre de priorité déclenche la création d'un ticket, l'intégration ITSM le transfère à l'équipe compétente en fonction des données relatives à la propriété des actifs ; chaque ticket comprend alors le délai prévu par le SLA, le niveau de risque et les consignes de résolution. Cela permet de combler le fossé de coordination entre la définition des priorités et la mise en œuvre. Au lieu que les équipes évaluent les risques a posteriori, le système génère des tâches sur lesquelles il est possible d'agir dès leur création.
Dans les environnements plus matures, les résultats des analyses de vulnérabilité sont également intégrés à un système de gestion des informations et des événements de sécurité (SIEM) afin d'être mis en corrélation avec les détections de menaces en cours. Une vulnérabilité qui apparaît également dans les journaux d'événements de menaces est automatiquement transmise à un niveau supérieur, sans passer par la file d'attente standard.
Les plateformes SOAR (Security Orchestration, Automation, and Response) vont encore plus loin grâce à des scénarios de réponse automatisés « » , capables de déclencher des actions correctives directement à partir d’une alerte corrélée, ce qui réduit le délai entre la détection et l’intervention sans nécessiter d’intervention humaine.
Niveaux de SLA en fonction de la criticité des actifs
Toutes les vulnérabilités ne suivent pas le même calendrier de correction. Les niveaux du SLA reflètent le degré de criticité des actifs :
- Ressources de production exposées à Internet : - SLA prévoyant une résolution des incidents dans les 24 heures
- Systèmes de production internes : SLA en 72 heures
- Environnements de développement et de préproduction : SLA de 7 jours
Une escalade automatisée se déclenche lorsqu'un seuil est dépassé. Si un équipement connecté à Internet reste dans cet état pendant plus de 24 heures sans qu'aucune mesure corrective ne soit prise, le système signale le problème au responsable de cet équipement et à l'équipe de sécurité.
Les organisations soumises à la norme PCI DSS ou à des cadres de conformité similaires ( ) peuvent être soumises à des délais de correction imposés en externe qui prévalent sur les niveaux de SLA internes. Ces éléments doivent être intégrés de manière explicite dans la logique d'escalade automatisée.
Le déficit de responsabilité
Voici une question à laquelle la plupart des programmes n'ont pas répondu : lorsque l' d'automatisation déploie un correctif et que le terminal ne confirme pas la résolution, à qui incombe la responsabilité de cette exception ?
Si la réponse est « cela dépend », c'est qu'il existe une lacune en matière de gouvernance.
Les exceptions non résolues constituent précisément le type de vulnérabilité que les auteurs de ransomware et autres acteurs malveillants recherchent activement et exploitent. Définissez explicitement à qui appartient l'exception. En règle générale, c'est le service informatique qui est responsable des échecs de déploiement (le correctif ne s'est pas installé). Le service de sécurité est responsable des échecs de validation (le correctif a été installé, mais la vulnérabilité persiste).
Validation et gestion des exceptions
« Déploiement confirmé » ne signifie pas la même chose que « exposition clôturée ».
Un correctif peut être déployé avec succès tout en laissant la vulnérabilité exploitable, car le service n'a pas redémarré, la configuration n'a pas été mise à jour ou le correctif n'a pas pris en compte la variante présente sur le terminal.
Que vérifie cette validation ?
L'automatisation de la validation permet de vérifier que la mesure corrective a bien éliminé la vulnérabilité, et pas seulement qu'une action a été effectuée. Cela comprend une nouvelle analyse automatisée après le déploiement du correctif afin de vérifier que la vulnérabilité n'apparaît plus dans les résultats de l'analyse, ainsi qu'une vérification de l'état des terminaux pour s'assurer que le correctif est bien présent et actif. Pour les corrections liées à la configuration, la validation permet de s'assurer que le changement d'état souhaité a bien pris effet.
En cas d'échec de la validation
Lorsque la correction ne permet pas de résoudre le problème, le processus doit redémarrer automatiquement. Les incidents sont réintégrés dans la file d'attente de priorisation avec un indicateur signalant un échec de résolution antérieur. La différence réside dans le fait de savoir si les échecs sont gérés dans le cadre du flux de travail ou s'ils font l'objet d'un suivi manuel.
Les défaillances répétées ou les problèmes liés à la configuration ou à la compatibilité nécessitent une analyse humaine. Les faux négatifs, c'est-à-dire les cas où la validation indique que le problème a été résolu alors que la vulnérabilité persiste, sont plus difficiles à détecter. Des analyses complètes périodiques, associées à des contrôles ciblés sur les actifs de grande valeur, permettent de réduire ce risque.
La surveillance continue comme moyen de validation
La surveillance continue ne constitue pas une étape distincte du cycle de vie, mais plutôt une fonction permanente de la couche de validation. Les nouvelles vulnérabilités découvertes sur des actifs déjà validés sont automatiquement réintégrées dans le flux de travail.
La distinction entre « déploiement confirmé » et « exposition clôturée » permet de différencier une automatisation aboutie d'une automatisation qui se résume à cocher des cases.
Les indicateurs qui comptent
Les indicateurs d'activité (analyses effectuées, tickets créés, correctifs déployés) montrent que le programme est très actif, mais ne permettent pas de déterminer s'il fonctionne. Pour déterminer si l'automatisation réduit réellement les risques, vous devez disposer d'un ensemble d'indicateurs différent.
Ces quatre indicateurs spécifiques à l'automatisation permettent de déterminer si votre programme produit des résultats concrets :
- Taux de couverture de l'automatisation : Cet indicateur mesure le pourcentage de vulnérabilités détectées qui sont entièrement traitées par des flux de travail automatisés (de la détection à la correction) sans aucune intervention manuelle. Un taux inférieur à 60 % indique généralement que le programme repose encore largement sur des processus manuels malgré les investissements réalisés dans des outils, même si l'objectif approprié dépend de la composition des actifs de l'organisation et de sa tolérance au risque.
- Taux de réussite des corrections automatisées : Cet indicateur mesure le pourcentage d'actions de correction automatisées dont la clôture a été confirmée par la couche de validation dès la première tentative. Un taux inférieur à 85 % indique des lacunes en matière de gouvernance. Il se peut que les correctifs soient déployés sur des classes d'actifs incorrectes ou que leur déploiement échoue en raison de problèmes liés à l'état des terminaux.
- Taux de faux positifs dans les flux de travail automatisés : Cet indicateur mesure le pourcentage de résultats qui ont fait l'objet d'une escalade suite à la hiérarchisation automatisée, mais qui se sont avérés non exploitables ou déjà corrigés. Un pourcentage supérieur à 15 % indique que les paramètres de priorisation doivent être ajustés.
- Clôture automatisée par niveau : Cet indicateur, généralement désigné sous le nom de MTTR, mesure la durée totale du cycle automatisé, de la détection à la clôture validée, ventilée par niveau de SLA. Si les ressources de production connectées à Internet dépassent 24 heures, il existe un goulot d'étranglement entre la hiérarchisation des priorités et la résolution des problèmes.
| Système métrique | Référence en matière de santé | Seuil d'alerte |
|---|---|---|
| Taux de couverture de l'automatisation | >60% | <40% |
| Taux de réussite de la remise en état | >85% | <70% |
| Taux de faux positifs | <15% | >25% |
| Délai moyen de résolution (niveau 1) | <24 hours | >48 heures |
Un taux de couverture élevé de l'automatisation associé à de faibles taux de réussite indique une automatisation mal mise en œuvre, tandis qu' des taux de réussite élevés associés à une faible couverture indiquent des processus manuels efficaces mais qui ne sont pas évolutifs.
Mais ces deux situations renvoient souvent à un même problème sous-jacent : des processus de travail déconnectés et des données fragmentées.
Lorsque l'analyse, la hiérarchisation, la correction et la validation s'effectuent à l'aide d'outils distincts utilisant des ensembles de données différents, les équipes consacrent davantage de temps à transférer des informations d'un système à l'autre qu'à corriger les vulnérabilités. Le problème de coordination s'aggrave lorsque le service de sécurité identifie des vulnérabilités, mais que le service informatique ne partage pas le même sentiment d'urgence ni le même sens des responsabilités. Chaque équipe part d'une vision différente.
C'est là que la plupart des stratégies d'automatisation échouent : la gestion automatisée des vulnérabilités ne fonctionne que lorsque chaque étape s'appuie sur des données à jour et alimente l'étape suivante, ce qui nécessite des données partagées en temps réel permettant d'éliminer les lacunes de coordination tout au long du flux de travail.
Comment Tanium prend en charge la gestion autonome des vulnérabilités tout au long de leur cycle de vie
La plateforme informatique autonome Tanium d' , , a été conçue pour centraliser le processus de gestion des vulnérabilités au sein d'une seule et même plateforme, avec des données partagées en temps réel sur les terminaux à chaque étape. Cela signifie que les équipes informatiques et de sécurité peuvent s'appuyer sur le même ensemble de données fiables, ce qui contribue à éliminer les goulots d'étranglement liés à la coordination qui ralentissent généralement la mise en œuvre des mesures correctives.
Voici comment Tanium contribue à automatiser et à rationaliser les étapes clés du cycle de vie de la gestion des vulnérabilités :
- Analyse continue et en temps réel : Tanium Exposure Management analyse chaque terminal et chaque ressource connectée à Internet afin de détecter les vulnérabilités et les écarts de conformité, avec une mise à jour régulière du contenu. Ce système remplace les cycles d'analyse périodiques qui obligent les équipes à travailler à partir de données pouvant dater de plusieurs jours, voire de plusieurs semaines, au moment où les mesures correctives sont mises en œuvre.
- Remédiation contrôlée et par étapes : Les déploiements progressifs, organisés en anneaux, commencent par un petit groupe de terminaux et s'étendent à mesure que chaque étape répond aux critères de réussite. Les « Tanium Confidence Scores » aident les équipes à faire la distinction entre les correctifs à faible risque, qui peuvent être automatisés en toute sécurité, et les modifications à haut risque, qui nécessitent une vérification humaine.
- Validation en boucle fermée : Une fois les correctifs appliqués, la plateforme vérifie leur état et identifie les systèmes qui n'ont pas pu être mis à jour. Cela permet de faire la distinction entre « tentative de déploiement » et « vulnérabilité confirmée comme corrigée ». Les résultats qui ne passent pas la validation sont automatiquement réintégrés dans la file d'attente de hiérarchisation, afin qu'aucun élément ne passe entre les mailles du filet.
Recovery Centers of America a utilisé Tanium pour détecter 400 000 vulnérabilités sur 2 200 terminaux qui n'avaient pas été repérées auparavant, puis a réduit ce nombre de 80 % en un peu plus de deux semaines. L'organisation a également réduit ses coûts informatiques, exprimés en pourcentage du chiffre d'affaires annuel, de 10 % à 3 %. Consultez l'étude de cas « ».
«Sans Tanium, nous devrions consacrer beaucoup plus de temps à l’application des correctifs sur nos terminaux, nos postes de travail et nos serveurs. » Nous n’aurions certainement pas le temps de nous consacrer aux autres tâches qui se présentent au quotidien. »Kris Matura, ingénieur réseau chez Recovery Centers of America
Le passage de la gestion traditionnelle des vulnérabilités à la gestion autonome des expositions ne se résume pas à une simple mise à niveau technologique. Les cadres de gouvernance, les modèles de propriété et les procédures de validation déterminent si l'automatisation permet d'obtenir des résultats ou si elle se contente d'accélérer le rythme des activités.
L'approche de plateforme unifiée de Tanium répond à ce besoin en reliant la détection, la hiérarchisation, la correction et la validation à partir de données partagées sur les terminaux, ce qui permet aux flux de travail de passer sans heurts d'une étape à l'autre et à l'automatisation de boucler la boucle.
Foire aux questions sur la gestion automatisée des vulnérabilités
La gestion automatisée des vulnérabilités est un domaine complexe et en constante évolution, ce qui rend difficile le maintien à jour et la bonne gouvernance des programmes. Vous trouverez ci-dessous quelques questions fréquemment posées par les équipes d'entreprise concernant les programmes de gestion automatisée des vulnérabilités et les outils qui les accompagnent.
Quelles sont les 5 étapes de la gestion des vulnérabilités ?
Une évaluation approfondie des vulnérabilités de l' , disponible à l'adresse , sous-tend chacune de ces étapes, garantissant ainsi que les résultats ne sont pas simplement répertoriés, mais bien analysés afin d'évaluer les risques concrets. Les cinq étapes principales sont la détection (analyse continue visant à identifier les vulnérabilités), l'évaluation (analyse des résultats pour déterminer leur gravité et leur exploitabilité), la hiérarchisation (classement des vulnérabilités par niveau de risque à l'aide des renseignements sur les menaces et de la criticité des actifs), la correction (application de correctifs ou de modifications de configuration) et la validation (vérification que la vulnérabilité a bien été corrigée, et non pas simplement confirmation du déploiement d'un correctif).
Quelle est la différence entre un scan ASV et un test d'intrusion ?
Une analyse réalisée par un prestataire de services de scan agréé (ASV) est une analyse automatisée des vulnérabilités, axée sur la conformité, qui identifie les failles potentielles depuis l'extérieur, tandis que les tests d'intrusion consistent en une tentative manuelle, menée par un professionnel de la sécurité, d'exploiter ces vulnérabilités afin de déterminer le risque et l'impact réels.
Quels types d'outils sont utilisés pour l'analyse automatisée des vulnérabilités ?
Les outils d'analyse des vulnérabilités se répartissent en deux grandes catégories : les plateformes basées sur des agents, qui déploient un logiciel sur chaque terminal pour assurer une surveillance continue, et les scanners sans agent, qui analysent les systèmes à distance à intervalles réguliers. Le choix entre ces deux options dépend des exigences en matière de fréquence d'analyse, de l'architecture du réseau et de la capacité de l'outil d'analyse à s'intégrer directement aux processus de correction et de validation.
Quels sont les 4 types de vulnérabilités dans les programmes de sécurité ?
Les quatre principales catégories de vulnérabilités sont les vulnérabilités réseau (services exposés, protocoles peu sécurisés), les vulnérabilités applicatives (failles logicielles, code non sécurisé), les vulnérabilités de configuration (paramètres peu sécurisés, identifiants par défaut) et les vulnérabilités humaines (cibles d'ingénierie sociale , formation insuffisante) ; toutefois, les programmes automatisés de gestion des vulnérabilités se concentrent principalement sur les trois premières.
L'automatisation de la gestion des vulnérabilités nécessite davantage que de simples outils isolés. Il s'agit de relier chaque étape du cycle de vie afin que les actions s'enchaînent de manière fluide, de l'analyse à la résolution.
Prenez rendez-vous pour une démonstration gratuite et personnalisée afin de découvrir comment Tanium automatise la gestion des vulnérabilités grâce à des données unifiées, des flux de travail coordonnés et une validation continue.
