La correction des vulnérabilités est l'un des domaines les plus exigeants sur le plan opérationnel dans le domaine de la cybersécurité. Mais l'identification des vulnérabilités est rarement le point faible de ces programmes. Pour de nombreuses organisations, le véritable défi consiste à mettre en œuvre les mesures correctives de manière cohérente et à vérifier l'efficacité de ces dernières dans des délais très serrés.
Cet article se concentre sur les mécanismes de mise en œuvre : transformer une liste hiérarchisée en plan de déploiement, déterminer quand il convient de corriger un problème plutôt que d'en atténuer les effets, gérer l'automatisation en toute sécurité, assurer la coordination entre les équipes et vérifier que les corrections ont bien éliminé la vulnérabilité. C'est la compréhension du processus de correction des vulnérabilités dans son ensemble, et non pas seulement de ses étapes individuelles, qui distingue les programmes qui réduisent systématiquement les risques de ceux qui génèrent une activité sans résultats mesurables.
En quoi consiste réellement la correction des vulnérabilités ?
Les différents types de vulnérabilités rencontrées par votre programme, notamment les failles logicielles, les erreurs de configuration et autres failles de sécurité, nécessitent chacun des approches de correction différentes. La correction des vulnérabilités désigne le processus consistant à éliminer ces failles de sécurité au sein des systèmes, des applications ou des configurations, après leur identification et leur hiérarchisation.
Il s'agit des phases d'exécution et de validation du cycle de vie de l' , dans le cadre de la gestion des vulnérabilités , au cours desquelles les résultats classés par ordre de priorité sont traduits en mesures correctives et en résultats validés. Dans le contexte plus large de la cybersécurité, la correction constitue le lien essentiel entre l'identification des vulnérabilités et la réduction des risques.
Bien que cela soit simple en théorie, c'est là que la plupart des programmes commencent à perdre du terrain.
Les mesures correctives échouent souvent lorsque les processus d'identification, de hiérarchisation et de mise en œuvre ne sont pas intégrés. Votre scanner a détecté une vulnérabilité CVE critique. La détection apparaît dans un tableau de bord de sécurité, tandis que les équipes informatiques travaillent à partir d'un système de tickets distinct, sans transfert cohérent entre les deux. Les jours passent. La vulnérabilité reste exposée, et ce retard prolonge directement le délai dont disposent les pirates pour l'exploiter.
Le passage de relais entre les équipes informatiques et SecOps constitue un autre point de défaillance courant. Les équipes de sécurité identifient les menaces et établissent un ordre de priorité. Le service informatique est responsable des systèmes et procède aux corrections. En l'absence d'une visibilité commune à la fois sur l'état d'avancement du déploiement et sur les résultats de la validation, les tickets sont clôturés prématurément de part et d'autre. Sans coordination, même les vulnérabilités dont la priorité a été correctement établie peuvent rester exposées.
Et puis, il y a le problème de la validation. Un correctif est déployé. La billetterie ferme. Mais cette vulnérabilité a-t-elle réellement disparu du terminal, ou est-elle toujours accessible ou exploitable par un autre moyen ? De nombreux programmes considèrent qu'un problème est résolu une fois que des mesures ont été prises, et non après avoir vérifié que la solution apportée a bien donné le résultat escompté.
Une fois les vulnérabilités classées par ordre de priorité, le défi ne consiste plus à déterminer ce qui est important, mais à mettre en œuvre les correctifs de manière fiable et à grande échelle.
Transformer une liste de vulnérabilités classées par ordre de priorité en un plan de correction
Vous disposez d'une liste classée par score des vulnérabilités. La prochaine étape consiste à transformer cette liste en une action coordonnée.
Décisions relatives au séquençage
Les scores de priorité orientent l'ordre de traitement, mais ne le dictent pas. Avant le séquençage, il est également utile d'éliminer les faux positifs : les résultats du scanner qui ne reflètent pas l'exposition réelle dans votre environnement alourdissent votre file d'attente et orientent à tort les efforts de correction. Une vulnérabilité notée CVSS 9,8 sur un serveur de test isolé est classée après une vulnérabilité notée CVSS 7,5 sur un contrôleur de domaine dans votre file d'attente de déploiement.
La hiérarchisation tient compte à la fois de la gravité et de la criticité des actifs, de l'exposition (par exemple, connexion à Internet ou réseau interne), des signaux d'exploitation active, ainsi que des contraintes opérationnelles telles que les créneaux de maintenance et les dépendances entre les systèmes. Il s'agit essentiellement d'une évaluation des risques menée au niveau des vulnérabilités, qui met en balance la probabilité d'exploitation et l'impact potentiel d'une attaque réussie sur l'activité.
Les sources d' s sur les menaces, telles que le catalogue des vulnérabilités connues exploitées (KEV) de la CISA et les scores du système de notation des prédictions d'exploitation (EPSS), permettent d'identifier les failles activement exploitées dans la nature. Les résultats de votre scanner doivent être recoupés avec une base de données sur les vulnérabilités, telle que la National Vulnerability Database (NVD), afin de garantir que les métadonnées CVE, les scores de gravité et les recommandations de correction soient à jour et interprétés avec précision en fonction du contexte. Les vulnérabilités critiques qui se situent à la croisée des critères « activement exploitées » et « sur un actif critique » doivent figurer en tête de votre liste de priorités.
Le catalogue KEV de la CISA fixe des délais de correction pour les agences fédérales ; de nombreux problèmes critiques doivent être corrigés dans des délais précis, en fonction du risque d'exploitation.
La hiérarchisation des priorités ne garantit pas à elle seule l'efficacité de l'exécution. Pour être efficaces, les programmes de correction doivent établir un lien entre les vulnérabilités identifiées et les correctifs, modifications de configuration ou mises à jour spécifiques nécessaires pour y remédier. Sans ce lien, les équipes perdent souvent du temps à transformer les CVE en mesures correctives concrètes. Les plateformes qui relient directement les données relatives aux vulnérabilités aux mesures correctives, telles que , qui identifie les correctifs manquants liés à des vulnérabilités actives, peuvent réduire les frictions entre les équipes de sécurité et les équipes informatiques et accélérer le délai de résolution en transformant les risques hiérarchisés en tâches exécutables au sein d’un même flux de travail.
Une fois les décisions relatives à l'ordre des tâches prises, la planification de l'exécution porte alors sur la répartition des responsabilités et l'affectation des ressources.
Répartition des ressources et des droits de propriété
Avant le déploiement du premier correctif, précisez qui est responsable de la mise en œuvre pour chaque niveau de priorité. Les vulnérabilités « zero-day » constituent le niveau de priorité le plus élevé et nécessitent généralement un processus accéléré avec des délais très courts. Les éléments classés comme « critiques » nécessitent souvent une procédure accélérée d'approbation des modifications d' ainsi que des ressources dédiées. Les interventions de niveau intermédiaire pourraient être regroupées lors des fenêtres de maintenance hebdomadaires.
Chaque élément de votre file d'attente génère généralement un ticket ITSM ou y est associé, avec les informations relatives au périmètre, aux actifs concernés, à la date limite et aux conditions d'approbation déjà renseignées. Ce ticket devient le principal point de coordination entre les services de sécurité et les opérations informatiques. Pour les problèmes de gravité élevée, il sert également de registre de communication destiné aux parties prenantes qui ont besoin d'être informées de l'avancement des mesures correctives et des délais prévus.
Exemple de workflow : Un CVE noté 9,8 selon le CVSS figure sur la liste KEV de la CISA à l'adresse 09 h . Le triage par priorité le classe dans la catégorie « critique ». Un ticket ITSM est généré automatiquement avec la liste des actifs concernés. Le Ring 1 est déployé sur 50 terminaux pilotes. Une nouvelle analyse de validation est effectuée à une fréquence définie, souvent toutes les quelques heures ou tous les jours, selon l'outillage et l'échelle. Ring 2 est déployé en production. La clôture nécessite des éléments probants issus de l'audit confirmant que le problème a été résolu.
Une fois le plan de déploiement mis en place, la décision suivante consiste à déterminer quel type de réponse convient à chaque vulnérabilité.
Remédiation, atténuation ou dérogation
Toutes les vulnérabilités ne font pas l'objet de la même réaction. Cette décision dépend de la disponibilité des correctifs, des contraintes opérationnelles et de la tolérance au risque.
| Type de réponse | Fonctionnalités | Quand l'utiliser |
|---|---|---|
| Remédiation | Élimine la vulnérabilité à la source | Un correctif fourni par l'éditeur est disponible et peut être déployé dans le respect de votre SLA |
| Atténuation | Réduit la vulnérabilité sans en éliminer la cause profonde | Aucun correctif n'est encore disponible, ou son déploiement nécessite des tests approfondis |
| Exception | Accepte formellement le risque sans le corriger ni l'atténuer | Soit le système doit être mis hors service, soit des mesures de contrôle compensatoires permettent de ramener le risque à des niveaux acceptables |
C'est souvent dans le choix du type d'intervention approprié que les programmes échouent. Évitez de recourir systématiquement à l'application de correctifs lorsque les contraintes opérationnelles rendent cette solution impraticable, et évitez de recourir systématiquement à des dérogations lorsqu'une solution corrective est disponible.
La correction constitue la solution la plus complète lorsque cela est possible, car elle élimine la vulnérabilité à la source. Cela implique notamment l'application de correctifs, le renforcement des configurations ou le remplacement des logiciels qui ne sont plus pris en charge, mais nécessite également une bonne coordination, des tests et une rigueur de déploiement pour réussir à grande échelle.
Les mesures d'atténuation permettent de gagner du temps. Cela réduit la vulnérabilité sans pour autant résoudre le problème sous-jacent, ce qui limite l'ampleur des répercussions pendant que les équipes attendent un correctif ou la validation complète. Cela en fait une solution utile sur le plan opérationnel, mais risquée si elle est considérée comme une solution à long terme.
Les exceptions génèrent une dette technique. Le fait d'accepter une vulnérabilité fait peser la responsabilité sur les instances de gouvernance : documenter la justification, maintenir des contrôles compensatoires et réexaminer la décision au fil du temps. Sans cette discipline, les risques acceptés ont tendance à s'accumuler sans que l'on s'en aperçoive.
Mise en œuvre de mesures correctives à grande échelle
Le déploiement de correctifs sur des milliers de terminaux sans provoquer d'interruptions de service nécessite une approche rigoureuse, et pas seulement des outils.
Application des correctifs des éditeurs
Le déploiement des correctifs suit un modèle par étapes. Procurez-vous le correctif, préparez-le en vue de sa distribution, puis testez-le sur un environnement hors production avant de procéder à son déploiement à grande échelle. Une gestion efficace des correctifs garantit que ce processus est reproductible et vérifiable, et ne se limite pas à une simple réaction aux CVE au fur et à mesure de leur apparition.
Le groupe pilote identifie les problèmes à un stade précoce. Si un correctif rompt une dépendance d'une application, perturbe son fonctionnement ou entraîne une baisse des performances, vous souhaitez en être informé sur 50 terminaux, et non sur 5 000. Les pauses entre les sonneries vous permettent d'observer les signaux de stabilité avant de passer à l'étape suivante.
Les terminaux déconnectés ou hors ligne constituent un défi particulier. De nombreuses plateformes permettent aux équipes de définir à l'avance des mesures correctives, mais leur mise en œuvre dépend toujours de la reconnexion du terminal et de la réception de ces instructions par celui-ci. Tant que la reconnexion n'est pas établie, les terminaux exposés restent vulnérables.
Remédier aux erreurs de configuration
La correction des paramètres de configuration ne se limite pas à « modifier un paramètre ». Vous détectez un écart par rapport à votre état de référence, vous créez un script ou appliquez la correction via une politique, puis vous vérifiez que la modification a été conservée après les applications suivantes de la politique.
Parmi les cibles courantes, on peut citer :
- Identifiants par défaut : . Les noms d'utilisateur et mots de passe définis par défaut que les pirates savent qu'ils doivent essayer en premier
- Ports ouverts inutiles : Points d'entrée du réseau qui élargissent la surface d'attaque
- Contrôles d'accès trop permissifs : Paramètres accordant un accès plus large que ce dont les utilisateurs ont besoin
Chacune d'entre elles correspond à un type de vulnérabilité courant que les attaquants recherchent et exploitent activement, ce qui fait du renforcement des configurations l'une des mesures correctives les plus efficaces à la disposition de la plupart des équipes. Les outils de gestion de la configuration assurent la mise en œuvre des modifications à grande échelle, mais c'est la vérification qui permet de s'assurer que cette mise en œuvre a bien eu lieu.
Mise à niveau ou remplacement des logiciels arrivés en fin de vie
Les logiciels en fin de vie (EOL) ne bénéficient plus des correctifs de sécurité d' . La mise en conformité consiste à passer à une version prise en charge, à remplacer le logiciel ou à le mettre définitivement hors service. Cela s'applique aussi bien aux composants commerciaux qu'aux composants open source. De nombreux environnements contiennent des bibliothèques open source en fin de vie (EOL) intégrées à des applications, qu'il est facile de négliger lors des cycles de correctifs habituels.
La remise en état des sites en fin de vie présente une grande complexité opérationnelle. La cartographie des dépendances vous indique ce qui ne fonctionne plus lorsque vous effectuez une mise à jour. Les tests permettent de s'assurer que la nouvelle version fonctionne correctement dans votre environnement. La validation par l'entreprise confirme la période de changement de production. Malgré leur complexité, les vulnérabilités liées à la fin de vie (EOL) constituent des cibles de correction à fort impact, car elles représentent une exposition persistante.
Mise en œuvre de contrôles compensatoires
Lorsque la mise en œuvre d'une mesure corrective directe n'est pas immédiatement possible, des contrôles compensatoires permettent de réduire le risque dans l'intervalle. Cela revêt une importance particulière pour les systèmes qui stockent ou traitent des données sensibles, pour lesquels une exposition non maîtrisée peut entraîner des conséquences réglementaires et commerciales allant au-delà du risque technique. Des mesures de contrôle telles que la segmentation du réseau, les restrictions d'accès et une surveillance renforcée contribuent à limiter les mouvements latéraux, à réduire la surface d'attaque et à améliorer la détection en cas d'exploitation.
Bien que les mesures de compensation soient souvent temporaires, elles peuvent, dans certains cas, rester en place à long terme et nécessiter une surveillance continue pour conserver leur efficacité à mesure que l'environnement évolue. Il est important de les suivre parallèlement aux exceptions, de les examiner régulièrement et de les remplacer par une solution définitive dès qu'un correctif est disponible.
Gestion de la correction automatisée
L'automatisation accélère l'exécution. Cela peut également entraîner la propagation d'erreurs de configuration ou d'échecs d'application de correctifs sur des milliers de terminaux en quelques minutes. La solution ne réside pas dans une réduction de l'automatisation. Il s'agit d'une automatisation régie par l' : une vitesse équilibrée par des contrôles qui détectent les problèmes avant qu'ils n'atteignent l'échelle de production.
Évaluation du niveau de confiance et éligibilité au déploiement
L' de notation de confiance fournit un contexte fondé sur les données afin d'aider les équipes à évaluer la sécurité d'un correctif ou d'une modification de configuration avant son déploiement. Plutôt que de prendre des décisions de manière automatique, ce système aide l'opérateur à se forger une opinion en mettant en évidence des indicateurs tels que la réussite des déploiements antérieurs, les résultats en matière de stabilité et l'impact sur les performances.
Les modifications présentant un niveau de confiance plus élevé peuvent constituer de meilleurs candidats pour un déploiement à plus grande échelle, tandis que celles présentant un niveau de confiance plus faible nécessitent généralement une validation supplémentaire, des tests ou une approbation explicite conformément à la politique de l'organisation.
Le déploiement par anneaux comme outil de gestion des risques
Déploiement en anneau : procède à un déploiement par étapes sur des groupes de terminaux de plus en plus importants. Une configuration type : « canary » (5–10 terminaux), « pilot » (50–200), « broad » (les autres).
La durée de pause entre deux sonneries est importante. Vous surveillez les taux d'échec des correctifs, les erreurs de compatibilité des applications et les indicateurs de stabilité des terminaux. Les seuils de défaillance par anneau déterminent à quel moment il faut interrompre ou revenir en arrière. Des critères d'escalade clairs permettent de déterminer qui est habilité à faire avancer ou à interrompre un déploiement.
Le déploiement en anneau est le mécanisme qui contribue à rendre l'automatisation plus sûre à l'échelle de l'entreprise.
Exécution basée sur un « playbook »
Les « playbooks » définissent la logique de correction automatisée, notamment le type de correctif à appliquer, l'étendue de son application et le déroulement du déploiement au sein des groupes de terminaux.
La mise en œuvre comprend souvent des étapes de validation et des déploiements progressifs, ce qui permet aux équipes d'examiner les modifications et de valider les résultats avant un déploiement à plus grande échelle.
La mise en œuvre du Playbook peut également s'intégrer aux flux de travail existants, notamment aux processus de gestion des tickets et de gestion des changements, afin que les mesures correctives et les validations s'alignent sur le mode de fonctionnement actuel des équipes.
Le problème de coordination entre les services informatiques et les opérations de sécurité (SecOps)
Le fait de savoir ce qu'il faut réparer et comment s'y prendre ne garantit pas que le problème soit résolu. La défaillance survient généralement au niveau du relais entre les services de sécurité et les opérations informatiques.
Quand la transition échoue
Les équipes de sécurité identifient les vulnérabilités et les classent par ordre de priorité. Les équipes chargées de l'exploitation informatique sont responsables des systèmes et procèdent aux corrections. En l'absence d'une visibilité commune sur l'avancement du déploiement, les résultats de la validation et la responsabilité des parties prenantes, les mesures correctives peuvent sembler achevées avant même que les corrections ne soient effectivement confirmées, ce qui laisse des vulnérabilités non résolues et des éléments probants d'audit incomplets.
Parmi les points de défaillance spécifiques, on peut citer :
- Le service de sécurité clôt un ticket lorsqu'une correction est « recommandée » : . Le service informatique ne l'a pas encore déployée.
- Le service informatique clôt un ticket lorsqu'un correctif est « déployé » : Le service de sécurité n'a pas encore vérifié que le correctif a bien corrigé la vulnérabilité.
- Pas de file d'attente partagée : Security fonctionne à partir d'un scanner de vulnérabilités . Le service informatique utilise un système de gestion des tickets issu de la gestion des services informatiques (ITSM). Il n'existe aucune traduction automatique entre ces deux langues.
- Divergence concernant le SLA : Security prévoit que les vulnérabilités CVE critiques seront corrigées dans un délai de 48 heures. Le service informatique dispose de fenêtres de gestion du changement qui ont lieu chaque semaine.
C'est au niveau du passage de relais entre les équipes informatiques et SecOps que de nombreux programmes de correction perdent du terrain — non pas parce que les équipes manquent de bonne volonté, mais parce que les processus ne s'articulent pas entre eux.
L'intégration ITSM en tant que couche de coordination
L'intégration des flux de travail ITSM joue un rôle essentiel pour combler les lacunes au niveau des transferts de responsabilité. Les rapports de vulnérabilité peuvent être configurés pour générer des tickets ITSM ou y être associés, avec les champs « périmètre », « priorité » et « date limite » préremplis. Les informations relatives à l'état du déploiement sont transmises par le service informatique à l'équipe de sécurité.
La visibilité partagée n'est pas facultative pour les programmes bien établis. Les deux équipes ont une vue d'ensemble en temps réel de l'état d'avancement de la correction d'une vulnérabilité. Les processus de validation concernent les deux équipes : qui valide avant le déploiement, qui confirme après.
Modèles de propriété partagée
Les programmes très performants définissent clairement les modalités de responsabilité. Un accord de niveau de service (SLA) commun en matière de remédiation, conclu entre les responsables SecOps et les responsables informatiques, définit les attentes. Les procédures d'escalade permettent de remédier aux retards. Une source unique et fiable permet de suivre l'état d'avancement des mesures correctives.
Les indicateurs permettent d'identifier les goulots d'étranglement. Le temps moyen de résolution (MTTR), suivi par étape (de la détection à la création du ticket, de la création du ticket au déploiement, et du déploiement à la validation), permet de déterminer si les retards proviennent de l'identification ou de l'exécution.
Vérifier que la mesure corrective a porté ses fruits
Le fait qu'un correctif ait été déployé ne signifie pas nécessairement que la vulnérabilité a été corrigée. La validation permet de vérifier si l'exposition est effectivement réduite ou éliminée, et pas seulement si elle a été prise en compte dans le processus.
De nombreux programmes corrigent les failles de sécurité une fois que des mesures ont été prises, et non après avoir vérifié que la correction a bien fonctionné. Cette distinction engendre une fausse confiance dans le niveau de sécurité et entraîne des lacunes dans les éléments probants de l'audit.
La validation nécessite généralement un analyse de vulnérabilité des terminaux concernés ou la vérification de l'état de ces derniers une fois le correctif déployé. Lors de l'application d'un correctif, assurez-vous que le CVE n'apparaît plus lors des analyses et que la vulnérabilité n'est plus présente ni accessible. En cas de modification de la configuration, vérifiez que le paramètre a bien été conservé et qu'il n'a pas été remplacé par l'application d'une politique ultérieure.
Dans les environnements distribués, effectuez une validation sur l'ensemble des ressources concernées, et non pas uniquement sur un échantillon, afin de vous assurer que la correction est bien appliquée à l'ensemble des éléments concernés. Dans d'autres contextes, la validation implique également de vérifier que la mesure corrective a directement remédié à la vulnérabilité initiale, et pas seulement qu'un changement a eu lieu.
Cette distinction est importante : « l'action effectuée » correspond à l'achèvement du processus. « Une réduction effective des risques » : tel est le résultat qui importe en matière de conformité, de preuves d'audit et de niveau global de sécurité.
Une fois la validation mise en place, la dernière question qui se pose est de savoir comment évaluer l'efficacité de votre programme.
Évaluation de l'efficacité des programmes d'assainissement
Les indicateurs vous permettent de déterminer si la mise en œuvre de vos mesures correctives est efficace et, le cas échéant, où intervenir.
Durée moyenne de la remise en état
Le MTTR mesure le temps écoulé entre la détection d'une vulnérabilité ou la création d'un ticket (selon la définition du programme) et la mise en œuvre d'une correction validée, ce suivi étant effectué par niveau de gravité.
Une augmentation du MTTR pour les éléments de niveau critique indique une défaillance quelque part dans le flux de travail. La comparaison entre le délai entre la détection et la création du ticket, celui entre la création du ticket et le déploiement, et celui entre le déploiement et la validation permet de déterminer si le retard provient de la hiérarchisation, de l'exécution ou de la validation. Le MTTR suivi au niveau du programme ne permet pas d'identifier précisément où se produisent les retards. Segmentez-le par étape.
Taux de couverture des mesures d'assainissement
Le taux de couverture mesure le pourcentage de vulnérabilités identifiées qui ont été corrigées dans le délai que vous avez défini.
Un MTTR élevé associé à un taux de couverture élevé indique une lenteur systématique, mais pas de défaillance du triage. Un faible taux de couverture indique soit un dysfonctionnement dans la hiérarchisation des priorités, soit des contraintes en termes de capacités des ressources. Suivez le taux de couverture par catégorie d'actifs. Le fait que des ressources critiques bénéficient d'une couverture inférieure à celle des terminaux standard révèle un problème de hiérarchisation des priorités.
Taux de conformité au SLA
Le SLA mesure le respect des délais de correction définis en fonction du niveau de gravité. Les objectifs de niveau de service (SLO) courants se présentent comme suit : « critique » dans un délai de 24–48 heures, « élevé » dans un délai de 7–14 jours, « moyen » dans un délai de 30 jours.
Les tendances en matière de non-respect des SLA, classées par niveau de gravité, permettent d'identifier précisément à quelle étape de votre processus d'exécution les ressources sont insuffisantes ou la gouvernance est défaillante. Le respect du SLA constitue le principal indicateur utilisé lors des audits de conformité. Les cadres réglementaires et les directives en matière de sécurité interne définissent souvent des délais de correction spécifiques en fonction du niveau de gravité. Ce sont les preuves documentées du déploiement et de la validation, et non pas simplement la clôture du ticket, qui permettent de satisfaire à ces exigences.
Le MTTR vous indique à quel point vous êtes lent. Le taux de couverture vous indique dans quelle mesure vous êtes complet. Le respect du SLA vous permet d'identifier les domaines dans lesquels vous ne respectez pas vos engagements. Tout programme de remédiation qui fonctionne sans ces trois éléments mesure les résultats, et non l'état de santé de l'exécution. Cet écart ne cesse de se creuser au fil du temps, à mesure que de nouvelles vulnérabilités sont découvertes.
Comment Tanium contribue à accélérer la correction des vulnérabilités
Les lacunes en matière d'exécution mises en évidence dans cet article, notamment la fragmentation des outils, les retards dans les transferts de tâches et une validation insuffisante, découlent souvent de flux de travail disjoints et d'une visibilité incomplète sur l'ensemble des terminaux.
La plateforme informatique autonome Tanium d’ , , permet de relier l’identification des vulnérabilités, les mesures correctives et les processus de validation grâce à une visibilité en temps réel sur les terminaux et à un contrôle de ceux-ci, réduisant ainsi le recours à des outils fragmentés.
Dans la pratique, cela se traduit par des fonctionnalités* telles que :
- Visibilité en temps réel sur les terminaux, associée à une évaluation à la demande des vulnérabilités et des configurations : Couvre les systèmes d'exploitation, les applications et les configurations, grâce à des bibliothèques de contenu régulièrement mises à jour
- Alertes en temps réel concernant les vulnérabilités critiques et émergentes : Diffusées via Tanium Guardian , en s'appuyant sur les travaux de recherche de l'équipe d'intervention d'urgence en matière de vulnérabilités (VERT) au sein de la console Tanium, et comprenant souvent des mesures correctives recommandées ainsi que des conseils
- Workflows de correction intégrés : Intervenez sur les vulnérabilités identifiées et lancez des workflows de correction au sein de la même plateforme afin de limiter la nécessité de passer d'un outil à l'autre
- Scores de confiance : Utilisez des indicateurs tels que les taux de réussite d'installation, les résultats en matière de stabilité et l'impact sur les performances pour éclairer vos décisions concernant l'application des correctifs avant un déploiement à plus grande échelle
- Déploiement progressif par étapes : Commence par un petit groupe de terminaux, vérifie les résultats, puis étend le déploiement à mesure que chaque étape répond aux critères de réussite
- Guides pratiques d'automatisation « low-code » et « no-code » : utilise Tanium Automate pour orchestrer les workflows liés aux terminaux et à la correction des incidents sous la supervision d'opérateurs
- Fonctionnalités de validation après déploiement : Permet de vérifier l'état des correctifs et d'identifier les systèmes sur lesquels les mesures correctives n'ont pas été appliquées comme prévu
- Intégration avec , ServiceNow et d'autres flux de travail clés : Permet aux équipes informatiques et de sécurité d'accéder à des données cohérentes sur les terminaux dans le cadre des processus existants
- Cas d'utilisation liés à l'évaluation de la configuration et à la gestion des vulnérabilités : Conformes à des référentiels courants tels que PCI, HIPAA et SOX
- de visibilité sur les mesures correctives : Met en évidence les vulnérabilités pouvant faire l'objet d'un correctif, les correctifs manquants et l'état d'avancement du déploiement afin d'aider les équipes de sécurité et d'exploitation à suivre la progression des mesures correctives et à coordonner leur mise en œuvre
*Les fonctionnalités et les résultats décrits s'appuient sur la documentation relative aux produits Tanium, sur des études de cas clients validées et sur des utilisations concrètes. Les résultats réels peuvent varier en fonction de l'environnement de déploiement, de la configuration et du niveau de maturité de l'organisation.
Avec Tanium, la validation peut être intégrée aux mêmes flux de travail que ceux utilisés pour déployer les mesures correctives. Les équipes peuvent vérifier l'état des terminaux, notamment le statut d'installation des correctifs ou les modifications de configuration, et réévaluer l'exposition afin de déterminer si les mesures correctives ont permis d'atteindre le résultat escompté.
C'est cette évolution, qui consiste à passer du suivi des mesures d'assainissement à la vérification de la réduction des risques, qui distingue les programmes aboutis des programmes réactifs.
La plupart des outils de conformité vous indiquent ce qui ne va pas. Peu d'entre elles vous indiquent comment y remédier, et presque aucune ne vous permet d'agir directement depuis le même écran. La fonctionnalité « Remediation Visibility » de Tanium Comply change la donne. Dans le cadre des Tech Talks n° 121 d’ , intitulés « », Margie Sills, architecte du domaine Risques et conformité chez Tanium, explique en détail comment cette fonctionnalité met en correspondance les vulnérabilités avec des correctifs exploitables, classés par impact en termes de réduction des risques, et comment les équipes peuvent passer de la détection à la correction sans changer d’outil ni attendre un transfert de responsabilité.
FAQ sur la correction des vulnérabilités
La mise en œuvre des mesures correctives soulève des questions pratiques qui ne trouvent pas toujours leur place dans la documentation relative aux processus. Vous trouverez ci-dessous les questions que les équipes posent souvent lorsqu'elles s'apprêtent à mettre en œuvre les résultats d'une analyse.
Mon outil d'analyse des vulnérabilités a détecté des centaines de CVE. Par où commencer ?
Le score CVSS à lui seul ne suffit pas pour établir un ordre de priorité. Une vulnérabilité CVSS 7,5 sur votre contrôleur de domaine constitue une cible d'exploitation prioritaire par rapport à une vulnérabilité CVSS 9,0 sur un système de test isolé.
Filtrez votre liste selon deux critères : le statut d'exploitation active (signaux CISA KEV et EPSS) et le niveau de criticité des actifs. Les éléments se situant à l'intersection entre « activement exploités dans la nature » et « sur une ressource critique » constituent votre première file d'attente d'exécution.
Pourquoi le score CVSS ne suffit-il pas pour établir l'ordre de priorité des correctifs à appliquer en premier ?
Le CVSS évalue la gravité de base et la gravité liée à l'environnement dans des conditions définies, mais ne tient pas compte de l'exploitation active ni du contexte métier. Il évalue l'exploitabilité et l'impact dans des conditions idéales pour l'attaquant, sans tenir compte du fait que la vulnérabilité soit activement exploitée dans la nature ni de l'importance du système concerné pour votre entreprise.
Un CVSS 9,8 concernant un logiciel qui ne fonctionne pas dans votre environnement est moins prioritaire qu'un CVSS 6,5 concernant un système activement exploité et connecté à Internet. Une séquence d'exécution efficace associe le CVSS à l'EPSS (probabilité d'exploitation) et à la criticité des actifs, et ne se fonde pas uniquement sur le score de gravité.
En quoi la remédiation diffère-t-elle de l'atténuation ?
La correction s'attaque à la vulnérabilité à la source au moyen de correctifs ou de modifications de configuration, tandis que l'atténuation réduit temporairement la possibilité d'exploitation grâce à des mesures de contrôle telles que la segmentation du réseau ou les restrictions d'accès, jusqu'à ce qu'une solution définitive soit disponible.
Pourriez-vous donner un exemple de correction d'une vulnérabilité ?
L'application d'un correctif fourni par un éditeur pour corriger une vulnérabilité CVE connue, le renforcement d'une règle de pare-feu mal configurée ou la mise à niveau d'un logiciel en fin de vie vers une version prise en charge constituent tous des mesures correctives, car elles traitent la vulnérabilité à la source plutôt que de se contenter de réduire l'exposition.
La correction des vulnérabilités ne consiste pas seulement à corriger ces dernières, mais aussi à s'assurer que le risque a bien été réduit. Les programmes qui intègrent la hiérarchisation, l'exécution et la validation au sein d'un flux de travail continu de type « » sont mieux à même de réduire les fenêtres d'exposition et de s'adapter à l'évolution des cybermenaces.
Prenez rendez-vous pour une démonstration afin de découvrir comment rationaliser et valider la correction des vulnérabilités dans l'ensemble de votre environnement grâce à Tanium.
