Gestion des vulnérabilités : guide pratique à l'intention des équipes informatiques et des MSP

La plupart des entreprises ont mis en place un système de gestion des vulnérabilités. Qu'il s'agisse d'un scan trimestriel, d'un processus de correction des failles ou d'un test d'intrusion annuel à des fins de conformité. Ce qui manque à la plupart d'entre elles, c'est un programme suffisamment rigoureux pour réduire réellement leur exposition aux risques.

Un scan trimestriel suivi d'un rapport dont personne ne tient compte ne constitue pas une gestion des vulnérabilités. Pas plus que l'application de correctifs lorsque les systèmes tombent en panne. Pas plus qu'un test d'intrusion annuel unique qui sert simplement à cocher une case avant d'être relégué dans un dossier. Une gestion efficace des vulnérabilités est un processus continu, fondé sur les données, qui consiste à identifier, hiérarchiser et corriger les failles d'un environnement informatique avant que les attaquants ne les exploitent, et ce, avec suffisamment de rapidité pour que la fenêtre d'exploitation reste réduite.

Selon le rapport Kaseya 2026 sur la situation des MSP, 53 % des MSP citent les problèmes de cybersécurité comme l'une de leurs principales préoccupations commerciales. Les vulnérabilités non corrigées constituent la cause la plus fréquente de la transformation de ces préoccupations en incidents. Téléchargez le rapport complet.

Qu'est-ce que la gestion des vulnérabilités ?

La gestion des vulnérabilités est un processus continu qui consiste à identifier, évaluer, traiter et signaler les failles de sécurité présentes dans l'environnement informatique d'une organisation. Elle couvre les vulnérabilités logicielles (correctifs manquants, CVE non corrigés), les failles de configuration (identifiants par défaut, ports ouverts inutiles, configurations de services non sécurisées) et les lacunes en matière de visibilité des actifs (appareils présents dans l'environnement qui ne sont ni surveillés ni gérés).

Ce processus est continu, car le paysage des vulnérabilités est en constante évolution. De nouveaux CVE sont publiés chaque jour. Les actifs changent. Des logiciels sont installés, mis à jour et désinstallés. L'environnement à la fin de ce mois est sensiblement différent de celui du début du mois, et un programme de gestion des vulnérabilités doit refléter cette réalité plutôt que de fournir un instantané ponctuel qui sera déjà obsolète avant même la diffusion du rapport.

C'est cette distinction qui différencie un programme de gestion des vulnérabilités d'une évaluation des vulnérabilités. Une évaluation permet d'identifier ce qui existe à un moment donné. Un programme, quant à lui, identifie, hiérarchise, corrige et vérifie en permanence les vulnérabilités dans un environnement en constante évolution.

Le cycle de vie de la gestion des vulnérabilités

Tout programme de gestion des vulnérabilités, quels que soient les outils utilisés ou son ampleur, suit le même cycle opérationnel.

L'inventaire et l'identification des actifs constituent la base. On ne peut pas protéger ce que l'on ne connaît pas. C'est un inventaire complet des actifs, incluant les appareils non officiellement enregistrés, l'informatique fantôme, les instances cloud et les appareils IoT, qui donne tout son sens à l'analyse. Une identification effectuée en continu plutôt que périodiquement est plus efficace, car de nouveaux actifs et de nouvelles vulnérabilités apparaissent entre les cycles d'analyse, et l'analyse d'un inventaire incomplet ne donne qu'une image partielle de la situation.

L'analyse et l'évaluation permettent de comparer les ressources aux bases de données répertoriant les vulnérabilités connues (CVE) et aux normes de configuration. La distinction entre analyse authentifiée et non authentifiée est essentielle. L'analyse non authentifiée, effectuée depuis la périphérie du réseau, permet de voir ce qu'un attaquant externe voit. L'analyse authentifiée, dans laquelle le scanner se connecte aux systèmes pour évaluer leur état interne, fournit des résultats nettement plus complets. La plupart des programmes sérieux de gestion des vulnérabilités utilisent les deux méthodes.

La hiérarchisation détermine l'ordre dans lequel les mesures correctives sont mises en œuvre. Toutes les vulnérabilités ne présentent pas le même degré d'urgence, et le nombre de résultats détectés dans un environnement réel est suffisamment important pour que la qualité de la hiérarchisation prime sur la couverture totale de l'analyse. Les cadres qui ont fait leurs preuves sont présentés en détail ci-dessous.

C'est au niveau de la correction que le programme apporte toute sa valeur ajoutée. La correction la plus courante consiste à appliquer des correctifs, mais les vulnérabilités peuvent également être traitées par des modifications de configuration, des contrôles compensatoires ou l'isolation des ressources concernées lorsqu'il n'est pas possible d'appliquer immédiatement un correctif. Les délais de correction doivent être définis par niveau de risque dans le cadre d'accords de niveau de service (SLA), et non selon un calendrier unique et uniforme qui traite de la même manière une faille CVE critique faisant l'objet d'une exploitation active et un problème de configuration de faible gravité.

La vérification boucle la boucle. Une fois les mesures correctives mises en œuvre, l'analyse doit confirmer que les vulnérabilités ont bien été corrigées. Des correctifs qui ne se sont pas installés correctement, des configurations qui ont été réinitialisées ou des contrôles compensatoires qui n'ont pas fonctionné comme prévu peuvent amener les organisations à croire qu'elles ont corrigé un problème alors que ce n'est pas le cas. C'est la vérification qui permet de transformer les mesures correctives en une réduction avérée des risques.

Les rapports s'adressent à plusieurs types de publics. Les équipes techniques chargées de suivre l'avancement des mesures correctives ont besoin de données détaillées et exploitables. Les rapports destinés à la direction sur l'état de la sécurité doivent fournir des données sur les tendances qui illustrent l'exposition aux risques au fil du temps. Les responsables de la conformité ont besoin de preuves attestant de la mise en œuvre continue de pratiques de gestion des vulnérabilités. Un programme qui ne produit qu'un seul de ces types de rapports sape sa propre utilité.

Analyse des vulnérabilités vs tests d'intrusion

Ces deux pratiques sont complémentaires et souvent confondues ; le fait d'utiliser l'une à la place de l'autre constitue une erreur courante dans la conception des programmes.

L'analyse des vulnérabilités est automatisée, exhaustive et continue. Elle identifie les vulnérabilités connues sur l'ensemble des ressources concernées, génère une liste hiérarchisée des résultats et fournit les données opérationnelles nécessaires au suivi des mesures correctives. Elle ne tente pas d'exploiter ces failles. Elle vous indique où se trouvent les faiblesses, mais ne précise pas si celles-ci sont réellement exploitables par un pirate expérimenté dans votre environnement spécifique.

Les tests d'intrusion sont manuels ou semi-automatisés, ciblés et périodiques. Un testeur expérimenté tente d'exploiter des vulnérabilités, y compris des chaînes de failles de faible gravité qui, prises isolément, semblent gérables, mais qui, combinées, permettent d'obtenir un accès significatif, afin de mettre en évidence des scénarios d'attaque réalistes. Les tests d'intrusion permettent de vérifier si vos défenses résistent à un attaquant expérimenté, et pas seulement de détecter l'existence de vulnérabilités.

Les deux sont utiles et permettent de répondre à des questions différentes. L'analyse de vulnérabilité est un programme opérationnel continu qui permet de maintenir à jour l'inventaire des expositions. Les tests d'intrusion, généralement réalisés une fois par an ou avant des changements architecturaux importants, permettent de vérifier si le programme opérationnel fonctionne réellement. Utiliser un test d'intrusion en remplacement d'une analyse continue est une erreur courante : le caractère ponctuel d'un test signifie qu'il ne détecte pas les vulnérabilités apparues après la date du test, ce qui, dans un environnement type, représente la plupart d'entre elles dans les 90 jours.

Définition des priorités : comment déterminer ce qu'il faut corriger en premier

L'objectif de la hiérarchisation n'est pas d'obtenir le nombre total de CVE le plus bas possible. Il s'agit plutôt de réduire les vulnérabilités les plus susceptibles d'être exploitées avant que vous ne puissiez toutes les corriger, car dans un environnement réel, il est impossible de toutes les corriger simultanément.

Les deux variables les plus importantes sont l'exploitabilité et la criticité de l'actif. Un score CVSS constitue un point de départ utile, mais il ne constitue pas à lui seul une indication suffisante. Une vulnérabilité CVSS 9 pour laquelle il n'existe aucun exploit public est moins urgente qu'une vulnérabilité CVSS 7 que le catalogue KEV (Known Exploited Vulnerabilities) de la CISA répertorie comme étant activement exploitée dans la nature. Le catalogue KEV est la référence publique la plus fiable concernant le statut d'exploitation active, et toute vulnérabilité qui y figure doit être traitée comme un élément de niveau 1, quel que soit son score CVSS.

Un cadre pratique en quatre étapes :

Niveau 1, correction dans un délai de 24 à 72 heures : vulnérabilités CVSS critiques sur des ressources exposées à Internet ou disposant de privilèges élevés ; toute entrée du catalogue KEV de la CISA ; vulnérabilités dont l'exploitation active a été confirmée par des données de renseignement sur les menaces.

Niveau 2, correctif à appliquer dans les 7 jours : vulnérabilités à score CVSS élevé ; vulnérabilités pour lesquelles des exploits de preuve de concept ont été publiés ; toute vulnérabilité affectant des ressources contenant des données sensibles ou permettant un accès privilégié.

Niveau 3, correctif à appliquer dans les 30 jours : vulnérabilités de gravité moyenne sur les terminaux standard.

Niveau 4, traitement dans le cycle de maintenance : vulnérabilités de faible gravité pour lesquelles il n'existe aucune preuve d'exploitation active.

Les vulnérabilités qui ne peuvent pas être corrigées dans les délais prévus (en raison de contraintes de compatibilité avec les applications critiques pour l'entreprise ou des processus d'approbation des modifications chez le client) doivent être formellement documentées, accompagnées de mesures de contrôle compensatoires et d'alertes de suivi. Une vulnérabilité non documentée, traitée avec une attitude du type « on s'en occupera plus tard », constitue un risque qui ne cesse de croître sans que personne n'en assure le suivi.

Gestion des vulnérabilités pour les MSP

Les MSP chargés de gérer des programmes de gestion des vulnérabilités dans plusieurs environnements clients ont besoin des mêmes fonctionnalités de base que les équipes informatiques d'une seule organisation, mais doivent également répondre à trois exigences supplémentaires : la multi-location, le reporting par client et une couche de hiérarchisation capable de mettre en évidence les éléments les plus urgents au sein d'un parc informatique global.

C'est dans le défi que représente la hiérarchisation des priorités par client que l'échelle fait toute la différence. Un MSP prenant en charge 40 environnements clients et effectuant un scan trimestriel des vulnérabilités peut mettre en évidence plusieurs centaines de CVE de haute gravité sur l'ensemble du parc. Sans un cadre permettant d'identifier immédiatement quelles vulnérabilités correspondent à des entrées CISA KEV et quels actifs présentent la plus grande criticité, le rapport devient ingérable et le programme se résume à « corriger ce qui est le plus facile ». Avec un tel cadre, la liste du premier jour est gérable : un ensemble spécifique de résultats critiques nécessitant une correction dans un délai de 24 à 72 heures, triés par client, le reste étant classé dans des files d'attente hebdomadaires et mensuelles.

L'infrastructure opérationnelle dédiée à la gestion des vulnérabilités à l'échelle d'un MSP comprend des politiques d'analyse standardisées appliquées de manière cohérente dans tous les environnements clients, avec des options de personnalisation par client concernant le calendrier, la portée et les identifiants d'accès des analyses ; des tableaux de bord des vulnérabilités par client offrant aux chargés de compte une visibilité sur l'exposition actuelle et la rapidité de correction ; des rapports destinés aux clients, adaptés aux discussions lors des revues trimestrielles des résultats (QBR), qui traduisent les listes CVE en un langage des risques adapté au contexte métier ; ainsi qu'un suivi des corrections lié aux accords de niveau de service (SLA) qui met en évidence la rapidité d'application des correctifs et prouve le respect des délais convenus.

VulScan, qui fait partie de la famille Kaseya via RapidFire Tools, propose une solution d'analyse des vulnérabilités réseau spécialement conçue pour les MSP, avec une détection automatisée et l'identification des CVE sur les réseaux des clients. Kaseya VSA 10 et Datto RMM se chargent du déploiement des correctifs, transformant les vulnérabilités identifiées directement en workflows de correction. IT Glue le contexte des actifs et la documentation, ce qui permet une hiérarchisation précise en fonction de la criticité des actifs, plutôt que de se baser sur des suppositions.

Découvrez comment la gestion des correctifs de Kaseya VSA 10 s'intègre à la détection des vulnérabilités.

Types de défaillances courants

Les programmes de gestion des vulnérabilités échouent de manière prévisible. Connaître ces schémas permet de les éviter plus facilement.

Une analyse sans suite. Les rapports de vulnérabilité qui identifient des problèmes sans alimenter un processus de correction n'ont aucune valeur en matière de sécurité. Une longue liste de CVE sans responsable désigné ni délai de correction ne fait que consigner les risques, elle ne les réduit pas.

Priorisation basée uniquement sur le CVSS. Un score CVSS mesure la gravité potentielle, et non la probabilité d'une exploitation effective. Considérer une vulnérabilité notée CVSS 9 pour laquelle il n'existe aucun exploit public comme plus urgente qu'une vulnérabilité notée CVSS 7 figurant dans le catalogue KEV de la CISA revient à faire fausse route. Les données relatives à l'exploitabilité issues du catalogue KEV et des flux de renseignements sur les menaces doivent être intégrées au modèle.

Actifs hors périmètre. Une gestion des vulnérabilités qui analyse le réseau de l'entreprise mais néglige les instances cloud, les appareils distants ou les infrastructures OT et IoT présente des failles que les pirates sauront exploiter, car ceux-ci effectuent des analyses exhaustives. Le périmètre doit refléter l'environnement réel, et non l'environnement tel qu'il a été documenté il y a deux ans.

Absence de responsable de la correction. Les vulnérabilités auxquelles aucun responsable n'est affecté ne sont pas corrigées. Chaque vulnérabilité identifiée doit avoir un responsable désigné, un accord de niveau de service (SLA) adapté au niveau de risque et un mécanisme de suivi. Une responsabilité sans échéance équivaut à une absence de responsabilité.

Pas de vérification. Vérifier qu'un correctif a été déployé ne revient pas à confirmer qu'une vulnérabilité a été corrigée. C'est l'analyse de vérification effectuée après la correction qui permet de transformer cette intervention en une réduction avérée des risques.

Kaseya Intelligence: de la détection à l'action autonome

Les outils traditionnels de gestion des vulnérabilités identifient les failles et formulent des recommandations. Le goulot d'étranglement opérationnel est toujours le même : un technicien doit examiner chaque résultat, le hiérarchiser par rapport à l'ensemble des autres tâches en attente, puis y donner suite à un rythme qui ne suit pas la vitesse à laquelle les vulnérabilités sont découvertes et exploitées.

Kaseya Intelligence sur plus de trois exaoctets de données agrégées et anonymisées et sur plus de 17 millions de terminaux gérés. La solution ne se contente plus de mettre en évidence les données relatives aux vulnérabilités, mais exécute de manière autonome des mesures correctives : application de correctifs, mise en quarantaine et validation des résultats, sans nécessiter d'intervention manuelle à chaque étape.

Pour les MSP qui gèrent des programmes de gestion des vulnérabilités dans des dizaines d’environnements clients, c’est le passage de la simple recommandation à l’action autonome qui rend le programme évolutif. Une équipe gérant 40 clients ne peut pas trier manuellement et traiter chaque vulnérabilité de niveau 1 dans un délai de 72 heures lors d’une semaine de « Patch Tuesday ». Grâce à des politiques de déploiement automatisé des correctifs qui s’appliquent selon des critères de niveau sans nécessiter l’approbation d’un technicien à chaque étape, c’est le système qui respecte ce délai de 72 heures, et non l’équipe qui le dépasse. Découvrez Kaseya Intelligence.

Une gestion des vulnérabilités bien menée passe inaperçue. Les correctifs sont déployés. Les résultats sont traités à tous les niveaux. Les analyses de vérification confirment la correction. Les rapports trimestriels montrent une courbe de tendance évoluant dans la bonne direction. Les clients dont les environnements sont gérés de cette manière ne subissent pas le type d'incidents causés par des vulnérabilités connues et corrigibles laissées ouvertes pendant des mois. Ceux qui ne sont pas gérés de cette manière découvrent, à travers les incidents, exactement quels modes de défaillance leur programme présentait parmi ceux mentionnés ci-dessus.