Guide · Gestion des vulnérabilités
Une faille connue depuis longtemps suffit parfois à compromettre un serveur qui n’a jamais reçu sa mise à jour. Dans une entreprise, le sujet arrive rarement au bon moment : il surgit quand un client demande une preuve, quand une alerte circule ou quand une machine tombe après une attaque. Cette page explique ce que recouvre la gestion des vulnérabilités, quand elle devient nécessaire et comment comparer les propositions.
Sommaire
Gestion des vulnérabilités, c’est quoi ?
Un cycle continu, pas une analyse ponctuelle
Une vulnérabilité est une faille dans un logiciel, un système ou un équipement, que son éditeur a identifiée et, le plus souvent, documentée. La gestion des vulnérabilités consiste à faire tourner en boucle quatre gestes : repérer, prioriser, corriger, vérifier. La boucle ne s’arrête pas, car de nouvelles failles apparaissent sur des logiciels que l’entreprise utilise déjà. Une analyse lancée une seule fois ne montre que l’état du parc le jour où elle a été faite.
Ce que recouvre le service
Le périmètre couvre les postes, les serveurs, les équipements réseau (pare-feu, commutateurs, bornes Wi-Fi, NAS, imprimantes) et les logiciels installés, y compris les logiciels tiers et les applications métier. Les scans peuvent être menés avec un accès qui lit l’intérieur des machines, ce qui révèle les correctifs manquants, ou sans authentification, depuis l’extérieur, pour voir ce qu’un visiteur distant peut atteindre. Le résultat n’a de valeur que s’il est trié. Une faille se priorise selon son exposition et l’importance de la machine touchée, et non sur son seul score de gravité, comme le score CVSS. Les avis publiés par le CERT-FR et les recommandations de l’ANSSI restent de bonnes sources pour suivre l’actualité des failles. Le test d’intrusion, lui, est une mission ponctuelle et manuelle qui mesure jusqu’où un attaquant pourrait aller : il se traite à part.
Quand faut-il s’en occuper ?
Plusieurs situations font remonter le sujet :
- Des serveurs qu’on n’ose plus redémarrer : la crainte de casser une application a fini par geler les mises à jour, et les machines accumulent le retard.
- Des mises à jour qui échouent en silence : rien ne les signale, et personne ne sait quels postes sont restés en arrière.
- Un rapport de scan que personne ne lit : l’analyse existe, mais elle s’empile sans décision ni suite donnée.
- Des équipements réseau oubliés : pare-feu, bornes Wi-Fi et imprimantes sortent rarement du cycle de mise à jour, alors qu’ils sont souvent exposés.
- Une faille très médiatisée : la direction veut savoir rapidement si l’entreprise est concernée, et l’informatique n’a pas de liste fiable pour répondre.
- Un logiciel métier en fin de support : il ne reçoit plus de correctifs, et l’entreprise découvre qu’il tourne toujours sur le réseau.
- Un client ou un assureur qui demande une preuve : il faut un suivi écrit des correctifs, et il n’existe pas.
Comment se déroule un projet
Une démarche de gestion des vulnérabilités s’installe en trois temps. Elle ne se règle pas en une journée, car chaque correctif touche au travail quotidien des équipes.
Avant de commencer
Le point de départ est un inventaire. On ne corrige que ce qu’on a recensé : la liste des postes, des serveurs, des équipements et des logiciels sert de base à tout le reste. Vient ensuite le cadrage des périmètres : quelles machines sont analysées, avec quel niveau d’accès, à quelle fréquence, et quelles fenêtres de maintenance restent acceptables pour les serveurs en production.
Pendant la mise en place
Les premières analyses donnent une photographie de l’existant. Le travail consiste alors à trier. Les failles graves et exposées passent en premier, les autres suivent un rythme planifié. Les correctifs s’appliquent par vagues, d’abord sur un groupe pilote qui sert de test, puis sur l’ensemble du parc si rien ne bloque. Les systèmes qui ne reçoivent plus de mises à jour sont isolés du reste du réseau, et chaque risque accepté est noté avec sa justification.
Après la mise en service
Le suivi reprend le cycle à intervalle régulier : nouvelles analyses, failles ouvertes, corrigées ou acceptées, machines qui ne remontent plus leur état. Un compte rendu écrit, lisible par la direction, rend la situation vérifiable. Sans ce rendez-vous, le parc se dégrade lentement, et personne ne voit le retard s’installer.
Ce qui distingue une bonne offre
Le prix dépend du parc et du rythme souhaité, et il ne se compare pas sans méthode. Deux propositions de même périmètre se départagent d’abord sur la manière dont les failles sont priorisées. Demandez si le classement tient compte de l’exposition réelle de chaque machine, de l’existence d’une exploitation connue et du rôle du système, ou seulement du score de gravité. Regardez ensuite comment les correctifs sont essayés avant d’être généralisés, et qui décide d’une exception. Le contenu du compte rendu compte aussi : une liste de failles sans état ni justification ne permet pas de prouver grand-chose. Vérifiez enfin que les équipements réseau et les logiciels tiers figurent noir sur blanc dans le périmètre, car ce sont souvent eux qui restent en arrière.
Les erreurs fréquentes
- Analyser sans inventaire : les machines inconnues restent hors du rapport. La parade consiste à tenir une liste à jour, qui sert de point de départ.
- Corriger selon le seul score de gravité : une faille modérée sur un serveur exposé passe alors après une faille élevée sur un poste isolé. La parade est un classement qui intègre l’exposition.
- Généraliser un correctif sans l’essayer : une mise à jour peut bloquer une application métier et laisser l’équipe méfiante pendant longtemps. La parade est un groupe pilote et un plan de retour arrière.
- Oublier les logiciels tiers et les équipements : seul le système d’exploitation est mis à jour, pendant que le navigateur, le pare-feu ou le NAS restent anciens. La parade est de les inscrire au périmètre dès le départ.
- Laisser un système en fin de support sans décision : le risque existe, mais personne ne l’a formellement accepté. La parade est de l’isoler, de le documenter et de prévoir son remplacement.
Les questions à poser avant de signer
Comment les failles sont-elles priorisées au-delà de leur score de gravité ? La réponse doit expliquer ce qui compte pour votre parc : exposition sur internet, exploitation connue, rôle de la machine. Un classement fondé sur un seul critère oriente mal les corrections.
Comment les correctifs sont-ils essayés avant d’être généralisés ? Demandez quel groupe sert de pilote, qui valide le résultat et comment un retour arrière se déclenche si une application métier est touchée.
Les équipements réseau et les logiciels tiers sont-ils inclus dans le périmètre ? Une liste écrite des machines, des équipements et des logiciels couverts évite les zones d’ombre les plus fréquentes.
Quel compte rendu sera remis, et à qui ? Un document qui montre les failles ouvertes, corrigées et acceptées, avec leur justification, permet à la direction ou à un client de vérifier le travail sans passer par l’informatique.
Pour démarrer, décrivez votre parc dans le formulaire : un spécialiste de la gestion des vulnérabilités vous recontacte, gratuitement et sans engagement.