Qu'est-ce qu'une évaluation des vulnérabilités ? Comment la mener, bonnes pratiques et exemples

Principaux enseignements

• Une évaluation de la vulnérabilité permet d'identifier, de classer et de hiérarchiser de manière systématique les failles de sécurité présentes sur vos réseaux, vos serveurs, vos applications et vos charges de travail dans le cloud, avant que les pirates ne les découvrent.
• Contrairement à un test d'intrusion, cette méthode n'exploite aucune faille ; elle cartographie vos risques afin que vous sachiez ce qu'il faut corriger et dans quel ordre.
• Le processus essentiel : recenser vos actifs, les analyser à l'aide des outils adaptés, les classer en fonction de leur vulnérabilité réelle (et pas uniquement en fonction du score CVSS), puis appliquer les correctifs de manière continue.
• La plupart des programmes échouent non pas à cause d'outils inadaptés, mais parce qu'ils considèrent l'évaluation comme un événement trimestriel plutôt que comme une pratique continue.

En moyenne, une entreprise recèle à tout moment des milliers de vulnérabilités connues – et l'écart entre leur découverte et leur correction ne cesse de se creuser, au lieu de se réduire. Le rapport 2026 de Verizon sur les enquêtes relatives aux violations de données révèle que l’exploitation des vulnérabilités est désormais le vecteur d’accès initial le plus courant, représentant 31 % des violations, contre 20 % l’année précédente. La plupart des équipes ne prennent conscience de leur exposition qu’à leurs dépens : après qu’un auditeur, un questionnaire de sécurité client ou un incident réel les a contraints à se pencher sur la question.

Une évaluation de la vulnérabilité consiste à anticiper les failles avant que quelqu’un d’autre ne les découvre. Lorsqu’elle est menée correctement, elle permet d’identifier les failles, d’évaluer leur gravité et de déterminer les priorités de correction. Lorsqu’elle est mal menée – ce qui est souvent le cas –, elle aboutit à un fichier PDF de 400 pages que personne ne lit.

Qu'est-ce qu'une évaluation des vulnérabilités ?

Une évaluation de la vulnérabilité est un processus systématique visant à identifier, classer et hiérarchiser les failles de sécurité présentes dans votre environnement informatique et vos systèmes d'information. Elle aboutit à une liste classée par ordre d'importance des problèmes (CVE, erreurs de configuration, identifiants faibles, services exposés), mise en correspondance avec les actifs qu'ils affectent et les risques qu'ils présentent.

C'est une approche descriptive, et non conflictuelle. Un audit de sécurité peut évaluer si vos contrôles sont conformes à un référentiel. Une analyse « zero-trust » remet en question votre modèle d'accès. Une évaluation des vulnérabilités répond à une question plus précise : où se trouvent, à l'heure actuelle, les failles ? Qu'il s'agisse de paramètres par défaut non sécurisés, de mots de passe administrateur faciles à deviner, de correctifs manquants ou de mécanismes d'authentification faibles que personne n'a pris le temps de renforcer.

Comment fonctionne l'évaluation des vulnérabilités ?

Le fonctionnement est plus simple que ne le laisse entendre la campagne marketing. La plupart des évaluations suivent ce cycle :

• Inventaire des ressources : répertoriez tout ce qui se trouve réellement sur votre réseau, y compris les éléments qui n’ont été documentés par personne.
• Analyse : effectuez des analyses authentifiées et non authentifiées sur ces ressources afin de détecter les problèmes connus.
• Corrélation : croiser les résultats avec les bases de données sur les vulnérabilités (NVD, avis des éditeurs, KEV) afin d'en déterminer la gravité et le contexte.
• Rapports : produisez quelque chose qui permette à un être humain d'agir, pas seulement un fichier CSV de 12 000 lignes.
• Transfert des mesures correctives : présentez les résultats à l'équipe qui sera chargée de les corriger, en fournissant suffisamment de contexte pour qu'elle n'ait pas à deviner ce que l'outil d'analyse a voulu dire.

Différents types d'évaluations de vulnérabilité

Les différentes couches de votre pile nécessitent des approches différentes. Se contenter d'effectuer un scan du réseau et de déclarer que votre application est sécurisée revient à commettre une erreur de catégorie. La plupart des programmes aboutis combinent plusieurs de ces éléments :

• Évaluations basées sur le réseau : analysent des plages d'adresses IP à la recherche de services exposés, de pare-feu mal configurés, de protocoles SSL/TLS peu sécurisés et de services non authentifiés. Il s'agit de l'analyse externe classique.
• Évaluations au niveau des hôtes : analyses authentifiées des serveurs et des postes de travail visant à détecter les correctifs manquants, les configurations non sécurisées et les logiciels locaux présentant des risques. Permet de détecter ce que les analyses réseau ne repèrent pas.
• Évaluations des applications : SAST, DAST et SCA sur vos bases de code, permettant de détecter des problèmes tels que les injections SQL (SQLi), les attaques XSS et les dépendances non sécurisées avant qu’ils n’atteignent l’environnement de production. Les projets modernes intègrent des dizaines, voire des centaines de dépendances transitives – c’est-à-dire les dépendances de vos dépendances –, ce qui fait des vulnérabilités de la chaîne d’approvisionnement une partie importante de la surface d’attaque des applications.
• Évaluations des bases de données : recherchez les comptes par défaut, les cryptages faibles, les privilèges excessifs et les versions de bases de données non mises à jour.
• Évaluations du cloud : évaluez les politiques IAM, les compartiments de stockage exposés, les images de conteneurs et les configurations d'exécution sur AWS, GCP et Azure.
• Évaluations des réseaux sans fil : détectez les points d'accès non autorisés, les protocoles vulnérables et les réseaux invités mal configurés.

Conseil de pro : Les analyses authentifiées détectent un nombre d'infractions bien supérieur à celui des analyses non authentifiées, mais elles sont plus difficiles à mettre en place et leur exécution peut s'avérer politiquement délicate. Si votre budget ne vous permet d'effectuer qu'un seul type d'analyse des serveurs, optez pour l'analyse authentifiée. Les analyses non authentifiées vous indiquent ce que voit un utilisateur externe ; les analyses authentifiées vous indiquent ce que voit un attaquant après avoir pris pied dans le système.

Avantages et inconvénients de l'évaluation des vulnérabilités

Une évaluation des vulnérabilités fait partie des mesures de sécurité offrant le meilleur retour sur investissement, mais ce n'est pas une solution miracle. Savoir dès le départ ce qu'elle permet et ce qu'elle ne permet pas d'éviter bien des déceptions par la suite.

Comment réaliser une évaluation des vulnérabilités : 4 étapes qui comptent vraiment

La plupart des listes d'étapes publiées sont trop chargées. En résumé, le travail se décompose en quatre phases. Chacune d'entre elles échoue de manière prévisible, et c'est en sautant l'une d'entre elles que les programmes finissent par générer des rapports dont personne ne tient compte.

Étape 1 : Définir le périmètre et dresser un inventaire des actifs

On ne peut pas évaluer ce qu’on ne voit pas. Avant de lancer un scan, il faut disposer d’un inventaire à jour des hôtes, des services, des applications et des ressources cloud, ainsi que d’une définition claire de ce qui est inclus et de ce qui est exclu. Cela peut sembler fastidieux, mais c’est le facteur le plus déterminant pour savoir si le reste de l’évaluation sera utile.

Une équipe SaaS de 40 personnes utilisant AWS découvre généralement 20 à 30 % d’actifs supplémentaires par rapport à ses prévisions lors de son premier inventaire complet : des environnements de préproduction oubliés, des ordinateurs portables de prestataires toujours répertoriés dans l’annuaire, une ancienne instance EC2 que quelqu’un a lancée en 2021 et qui n’a jamais été mise hors service. C’est au niveau du « shadow IT » (comptes cloud, outils SaaS et environnements de développement mis en place à l’insu du service informatique) que l’écart est généralement le plus important.

Définissez par écrit le périmètre de l'analyse. Précisez les plages d'adresses IP, les domaines, les comptes et les exclusions. Indiquez tous les systèmes sur lesquels l'analyse authentifiée est interdite et expliquez pourquoi. Si vous ignorez cette étape, vous devrez réexécuter les analyses pendant des semaines, car personne n'aura signalé à l'équipe de sécurité que le cluster de développement se trouvait dans un autre VPC.

Étape 2 : Effectuer une analyse à l'aide des outils et des identifiants appropriés

Choisissez un scanner adapté au niveau que vous souhaitez évaluer (réseau, hôte, application, cloud) et exécutez-le en utilisant les identifiants appropriés. Pour les évaluations au niveau de l'hôte, cela implique un accès SSH ou WinRM avec des privilèges suffisants pour consulter les versions des paquets et les fichiers de configuration.

La fréquence des analyses est plus importante que le choix de l'outil. Un scanner exécuté chaque semaine et ciblant les éléments pertinents sera plus efficace qu'un scanner « haut de gamme » exécuté une fois par trimestre. Pour les systèmes Linux en particulier, il est préférable d'effectuer des analyses en se basant sur les avis des éditeurs et les bases de données de vulnérabilités plutôt que sur les entrées brutes du NVD : Red Hat, Canonical et SUSE intègrent les correctifs sans modifier les numéros de version ; par conséquent, une vérification CVE générique génère une multitude de faux positifs sur les systèmes déjà corrigés.

Attention : Les analyses authentifiées effectuées sur des bases de données de production ou des systèmes financiers peuvent déclencher des alertes IDS, verrouiller des comptes de service ou générer des centaines d’événements dans les journaux d’audit par hôte. Coordonnez-vous avec les équipes responsables de ces systèmes, planifiez des créneaux horaires et utilisez un compte de service dédié doté de privilèges en lecture seule. Un scanner qui verrouille votre compte de service à 3 heures du matin est un scanner que vous devez cesser d’utiliser.

Étape 3 : Triage et hiérarchisation – Pas uniquement en fonction du CVSS

Les données brutes issues des scanners ne sont qu’un flux de bruit non trié. C’est lors de l’étape de tri que les analystes en sécurité transforment les données d’évaluation des vulnérabilités en informations réellement exploitables – et c’est également à ce stade que la plupart des programmes cèdent face au volume de données. Le catalogue « Known Exploited Vulnerabilities » (KEV) de la CISA répertorie les CVE que les attaquants exploitent activement à l’heure actuelle. Il ne représente qu’une infime partie de l’ensemble des CVE publiées, et c’est cette liste que vous devez corriger en priorité, quel que soit le score CVSS.

Une pile de triage pratique :

1. Commencez par les vulnérabilités CVE répertoriées dans la liste KEV sur les ressources exposées à Internet. Ce sont les problèmes prioritaires.
2. Ajoutez les vulnérabilités CVE de gravité « critique » (CVSS 9.0+) aux ressources qui traitent des données sensibles ou qui se trouvent sur le chemin d'authentification.
3. Intégrer les scores EPSS pour estimer la probabilité d'exploitation dans la réalité.
4. Problèmes de déclassement sur des équipements isolés, non routables ou protégés par un système de contrôle de compensation.

C'est également là que de bons outils font la différence. TuxCare Radar, par exemple, prend en compte à la fois les données d'exploitabilité, les scores CVSS et le statut des correctifs confirmés ; ainsi, votre équipe ne se contente pas d'observer un simple score CVSS brut et de deviner ce qui est urgent.

Étape 4 : Corriger, vérifier et relancer l'analyse – en continu

Les failles non corrigées ne sont que de la poudre aux yeux – et les chiffres le confirment. Le rapport « 2026 Open Source Landscape Report » de TuxCare a révélé que 61,4 % des incidents de cybersécurité se sont produits alors qu’un correctif était déjà disponible, et que 92,6 % des organisations touchées savaient déjà qu’elles étaient vulnérables. Le problème ne réside pas dans la détection, mais dans la nécessité de combler le fossé entre la prise de conscience et la correction.

Rendez ce cycle continu. Des analyses quotidiennes ou hebdomadaires, dont les nouveaux résultats sont intégrés au même système de gestion des tickets que celui utilisé pour les corrections de bogues, surpassent les évaluations trimestrielles sur tous les plans significatifs.

Le principal obstacle n’est ni l’outillage ni le budget : 43 % des entreprises citent l’impossibilité de mettre hors ligne leurs systèmes critiques comme principal frein à l’application des correctifs. C’est pourquoi des outils de correction en temps réel comme KernelCare existent : les vulnérabilités CVE du noyau sont corrigées sans qu’il soit nécessaire de programmer une fenêtre de redémarrage. Pour les équipes utilisant des distributions Linux en fin de vie, pour lesquelles les correctifs en amont ont complètement cessé d’arriver, le service Endless Lifecycle Support (ELS) de TuxCare comble cette lacune sans imposer de migration immédiate.

Que contient un rapport d'évaluation de la vulnérabilité ?

Une analyse qui se termine par une exportation au format CSV que personne n'ouvre n'est pas une évaluation aboutie, mais simplement une analyse terminée. C'est le rapport qui permet de transformer les résultats en décisions. Au minimum, un bon rapport d'évaluation des vulnérabilités doit inclure :

• Nom de la vulnérabilité et identifiant CVE : afin que toute personne qui lit ces informations puisse les vérifier par elle-même
• Ressource concernée : nom d'hôte, adresse IP, service ou application
• Score CVSS : le niveau de gravité de base attribué par le NVD
• Contexte d'exploitabilité : figure-t-elle sur la liste KEV de la CISA ? Quel est son score EPSS ? Existe-t-il un code d'exploitation public ?
• État du correctif : corrigé, non corrigé, atténué ou risque accepté
• Action recommandée : correctif, modification de configuration, mesure corrective ou exception documentée
• Propriétaire et date limite : les deux champs que la plupart des rapports laissent vides, ce qui explique précisément pourquoi les incidents ne sont pas clôturés

Concrètement, le rapport doit être rédigé en deux versions : une version technique destinée aux ingénieurs chargés des travaux, et un résumé destiné à la direction, qui établit un lien entre les vulnérabilités et les risques opérationnels plutôt que de se limiter aux scores CVSS. Un score CVSS de 9,8 sur un système interne non exposé à l'extérieur ne doit pas être présenté de la même manière qu'un score CVSS de 7,5 sur votre service d'authentification public.

Les difficultés courantes et comment y faire face

Le travail est rarement entravé par le scanner. Ce sont généralement les interférences, les problèmes de coordination et la complexité architecturale qui font dérailler les véritables projets.

Faux positifs (et faux négatifs)

Les scanners signalent des éléments qui n'existent pas et en ignorent d'autres qui existent bel et bien. Au fil du temps, les faux positifs sapent la confiance dans le programme : dès qu'un ingénieur fatigué commence à ignorer les alertes du scanner, tout le dispositif perd de sa valeur. Les faux négatifs sont encore pires : ils laissent passer de véritables vulnérabilités.

La solution réside dans l'étalonnage, et non dans un scanner plus performant :

• Adaptez les profils d'analyse en fonction de chaque catégorie d'actifs. Un serveur web et un serveur de base de données nécessitent des vérifications différentes.
• Dans la mesure du possible, utilisez des analyses authentifiées pour vérifier les informations relatives à la version, plutôt que de vous fier aux bannières d'affichage du service.
• Croisez vos résultats avec les avis des éditeurs plutôt qu'avec les données CVE brutes, en particulier sur les distributions Linux d'entreprise qui intègrent des correctifs rétrospectifs. Il s'agit là d'une source étonnamment courante de faux positifs qui fait perdre un temps précieux aux ingénieurs.
• Tenez à jour une liste de suppression pour les faux positifs connus, en y indiquant des dates d'expiration afin que les suppressions ne perdurent pas sans que l'on s'en aperçoive, au-delà de la réalité sous-jacente.

TuxCare Radar a été spécialement conçu pour répondre à ce problème. Il sait faire la distinction entre une vulnérabilité CVE qui n’a effectivement pas encore fait l’objet d’un correctif et une autre qui a été corrigée en mémoire via un correctif du noyau en temps réel – un détail que les scanners génériques négligent systématiquement, générant ainsi des alertes pour des vulnérabilités que votre équipe a déjà corrigées.

Se tenir informé des nouvelles vulnérabilités

Le NIST publie chaque mois des milliers de nouveaux CVE, et ce rythme ne cesse de s'accélérer. Personne ne peut suivre le rythme en lisant manuellement tous les avis de sécurité. La solution pratique :

• Abonnez-vous aux listes de diffusion des fournisseurs et aux mises à jour KEV de la CISA, puis redirigez-les vers le même système de gestion des tickets que les résultats des analyses.
• Automatisez l'intégration des flux de renseignements sur les menaces dans votre scanner afin que les nouvelles signatures apparaissent dans les analyses en quelques jours, et non en quelques semaines.
• Suivez séparément les vulnérabilités liées à l'authentification : les failles d'authentification sont généralement exploitées très rapidement après leur divulgation.

Vous pouvez également utiliser le CVE Tracker de TuxCare pour suivre l'état des vulnérabilités et des correctifs sur l'ensemble des distributions Linux en fin de vie et des produits open source pris en charge.

Analyse d'environnements hybrides complexes

Un scanner conçu pour un réseau local plat tombe en panne dès que l’on ajoute un peering VPC, Kubernetes, des conteneurs éphémères et l’environnement SaaS d’un partenaire. L’analyse hybride est une discipline à part entière :

• Utilisez des agents de scan sur les hôtes à longue durée de vie et le scan du registre et des images pour les conteneurs à courte durée de vie.
• Intégrez des API natives du cloud (AWS Inspector, Azure Defender, GCP Security Command Center) plutôt que d'essayer d'analyser les charges de travail dans le cloud à partir d'un seul appareil sur site.
• Attribuez des balises aux ressources de manière cohérente dans tous les environnements afin que les résultats puissent être mis en corrélation par application et par responsable.
• Il faut accepter que certains actifs – fonctions sans serveur, services gérés – présentent un modèle de vulnérabilité différent et nécessitent une stratégie d'évaluation totalement différente.

L'objectif n'est pas de recenser toutes les vulnérabilités CVE, mais de veiller à ce que celles qui font l'objet d'une exploitation active ne restent jamais sans suite pendant plus de quelques jours.

Évaluation des vulnérabilités et tests d'intrusion

Ces deux notions sont souvent confondues dans les appels d'offres. Il ne s'agit pas de la même activité, et l'une ne remplace pas l'autre.

En termes simples : une évaluation passe tout en revue de manière superficielle ; un test d'intrusion cible quelques points de manière approfondie. Les évaluations permettent de détecter les CVE connues ; les tests d'intrusion permettent de mettre au jour des chaînes d'attaque, des failles logiques et, parfois, des vulnérabilités « zero-day ». Effectuez régulièrement des évaluations de vulnérabilité pour établir votre base de référence. Réalisez un test d'intrusion chaque année, avant tout lancement majeur ou lorsque le périmètre de votre système change de manière significative.

Outils et logiciels d'évaluation des vulnérabilités

Le marché des outils est très concurrentiel : il comprend aussi bien des scanners de vulnérabilités spécialisés que des outils de gestion de la surface d'attaque et des services d'analyse natifs du cloud. Le choix de la solution la plus adaptée dépend de votre infrastructure. Les parcs informatiques à forte prédominance Linux, les entreprises utilisant des solutions natives du cloud et celles où Windows est majoritaire ont chacune leurs points forts spécifiques.

TuxCare Radar

Radar est le scanner de vulnérabilités de TuxCare dédié à Linux. Il a été conçu pour remédier à un problème que la plupart des scanners génériques gèrent mal : les distributions Linux d'entreprise intègrent des correctifs de sécurité sans modifier le numéro de version. Les vérifications CVE génériques détectent une chaîne de version « ancienne » et signalent une vulnérabilité qui a pourtant été corrigée il y a plusieurs semaines.

Radar effectue des recoupements avec les données réelles issues des avis des éditeurs. Il prend également en charge les correctifs en temps réel (sans redémarrage) : ainsi, si KernelCare a déjà appliqué un correctif du noyau en mémoire, Radar sait que la vulnérabilité CVE est corrigée et ne la signalera pas comme ouverte. Ce n’est pas un détail anodin : c’est la différence entre un scanner qui vous indique votre niveau réel d’exposition et un autre qui génère du bruit que votre équipe finira par apprendre à ignorer.

Autres informations utiles concernant Radar : notation des risques assistée par IA, absence d'agent permanent et intégrations natives avec Qualys, Nessus et OpenSCAP pour les équipes qui disposent déjà d'une plateforme d'analyse et souhaitent simplement y intégrer des données Linux précises.

Vous voulez voir comment Radar fonctionne concrètement ?

Tenable Nessus

Un scanner polyvalent établi de longue date, offrant une large couverture de plugins pour les systèmes d'exploitation, les périphériques réseau et les ressources cloud. Idéal pour les organisations qui recherchent une solution unique capable de répondre à la plupart de leurs besoins et qui disposent du budget nécessaire pour les licences. Moins adapté aux subtilités liées au backporting sous Linux, qui peuvent entraîner des faux positifs sur les systèmes d'entreprise mis à jour.

Qualys VMDR

Solution de gestion des vulnérabilités hébergée dans le cloud, offrant une large couverture des actifs, des options avec ou sans agent, ainsi qu’une intégration étroite à la suite complète de Qualys dédiée à la conformité. Convient aux entreprises qui souhaitent s’appuyer sur un seul fournisseur pour l’analyse des vulnérabilités, des configurations et de la conformité. La tarification évolue en fonction du nombre d’actifs, ce qui peut rapidement devenir coûteux dans les environnements natifs du cloud.

OpenSCAP

Un framework open source dédié à la vérification automatisée de la conformité et à l'analyse des vulnérabilités, conçu autour des normes SCAP (Security Content Automation Protocol). Largement utilisé dans le secteur public, les secteurs réglementés et les environnements à forte présence de Linux où la conformité aux normes de référence du NIST et du CIS est obligatoire. Il nécessite des connaissances approfondies en configuration et en script pour obtenir des résultats exploitables, mais il est gratuit, auditable et s'intègre parfaitement aux pipelines d'automatisation Linux existants.

Meilleures pratiques en matière d'évaluation de la vulnérabilité

La différence entre un programme qui fonctionne et un autre qui reste dans un tiroir réside rarement dans le scanner. Elle tient plutôt à quelques habitudes de travail.

Personnalisation des profils de numérisation

Les profils d'analyse par défaut constituent un point de départ, et non une fin en soi. Un profil adapté à un serveur web peut mettre à rude épreuve une base de données ; un profil optimisé pour les terminaux Windows passera à côté de certains éléments sur un parc de machines Linux. Créez des profils par catégorie d'actifs, documentez-les et réexaminez-les tous les trimestres. Les outils tenant compte des distributions (c'est-à-dire ceux qui comprennent comment Red Hat ou Ubuntu gèrent le backporting) produisent des résultats nettement plus précis qu'un scanner générique fonctionnant avec les paramètres par défaut.

Travailler avec des équipes pluridisciplinaires

L'évaluation des vulnérabilités se situe à la croisée des équipes chargées de la sécurité, de l'infrastructure et des applications. Les résultats qui ne sont attribués à personne ne mènent nulle part. Mettez en place un processus dans lequel l'équipe de sécurité définit le périmètre et effectue le tri des résultats, l'équipe d'infrastructure se charge des corrections au niveau du système d'exploitation et du réseau, les équipes applicatives prennent en charge les corrections du code et des dépendances, et l'équipe de conformité reçoit les rapports dont elle a besoin sans que les équipes de sécurité aient à les mettre en forme manuellement.

Tenez à jour votre inventaire des actifs

L'inventaire obsolète est un « tueur silencieux ». Un scanner qui estime que vous disposez de 400 hôtes alors que vous en avez en réalité 530 passera à côté de 130 systèmes et ne vous en informera jamais. Intégrez la découverte des ressources au processus de provisionnement : chaque nouvelle machine virtuelle, image de conteneur ou compte cloud devrait automatiquement enrichir l'inventaire. Associez cette approche à des audits réguliers de configuration afin de détecter tout écart entre ce qui est provisionné et ce qui est réellement en cours d'exécution.

Automatiser l'analyse, tout en conservant une intervention humaine dans le processus de tri

L'automatisation gère le volume. L'humain se charge de l'évaluation. Programmez automatiquement les analyses, intégrez automatiquement les résultats dans un système de tickets, mais confiez à un humain la vérification de tout élément critique ou figurant sur la liste KEV. Une automatisation pure, sans supervision, entraîne une « fatigue des alertes » ; à l'inverse, une vérification entièrement manuelle ne peut pas s'étendre au-delà de quelques centaines d'hôtes.

Exemples concrets d'évaluations de vulnérabilité

Concrètement, cela peut prendre des formes très différentes selon le contexte. Voici quelques scénarios réalistes :

Exemple 1 : Plateforme SaaS sur AWS

Une équipe SaaS de 20 personnes effectue chaque semaine des analyses authentifiées sur son parc EC2, des analyses quotidiennes des images dans ses registres ECR, ainsi que des vérifications continues des politiques IAM via AWS Inspector. Les résultats sont transférés vers Jira et automatiquement attribués au responsable du service concerné. Les CVE critiques répertoriées par le KEV bénéficient d’un SLA de 7 jours ; pour toutes les autres, le délai est de 30 jours. Le délai médian de correction est passé de 45 à 9 jours en l’espace de six mois.

Exemple n° 2 : Entreprise de services financiers soumise à une réglementation

Une banque de taille moyenne réalise chaque trimestre des évaluations internes de vulnérabilité sur environ 8 000 hôtes, des analyses externes mensuelles et des analyses continues dans le cadre de la norme PCI. La gestion des rapports de conformité nécessite à elle seule un analyste GRC dédié. Pour les serveurs Linux critiques, elle utilise la solution de correction sans redémarrage de KernelCare, car la planification de fenêtres de correction perturbe les opérations et engendre des coûts élevés : KernelCare comble le fossé entre l'analyse et la correction sans modifier le calendrier de maintenance.

Exemple 3 : Production avec des systèmes OT hérités

Dans un environnement industriel, on trouve à la fois des serveurs Linux modernes et des machines Windows vieilles de 15 ans exécutant des automates programmables (PLC). Il est strictement interdit de procéder à des analyses actives du réseau OT : une analyse mal menée pourrait en effet arrêter une chaîne de production. L’évaluation repose sur une surveillance passive du réseau pour les actifs OT, des analyses authentifiées pour l’infrastructure informatique (IT), ainsi qu’une liste documentée des exceptions pour les systèmes qui ne peuvent pas être corrigés mais qui sont protégés par la segmentation du réseau. La découverte la plus intéressante : un poste Windows 2008 dont personne ne se souvenait était accessible depuis le réseau local de l’entreprise.

De l'évaluation à la remise en état effective avec TuxCare

Une détection sans correction n'est qu'une charge administrative coûteuse. Le véritable enjeu consiste à boucler la boucle — analyse, hiérarchisation, correction, vérification — à un rythme suffisamment rapide pour garder une longueur d'avance sur l'arriéré des vulnérabilités CVE.

TuxCare Radar se charge de l'analyse et de la hiérarchisation des vulnérabilités avec une précision propre à Linux. KernelCare gère la correction des vulnérabilités CVE du noyau sans nécessiter de redémarrage. LibCare étend cette fonctionnalité aux bibliothèques partagées telles qu’OpenSSL et glibc. Et pour les équipes exploitant des systèmes ayant dépassé leur date de fin de vie – CentOS 7, anciennes versions LTS d’Ubuntu ou environnements d’exécution de langages en fin de vie –, Endless Lifecycle Support continue de fournir des correctifs même après la fin du support par le fournisseur.

Si votre processus actuel génère plus de rapports que de correctifs, c'est là qu'il faut combler cette lacune. Découvrez comment TuxCare s'intègre dans un workflow de gestion continue des vulnérabilités et dans un programme plus large de gestion des risques informatiques.

Résumé

Nom de l'article

Qu'est-ce qu'une évaluation des vulnérabilités ? Comment la mener, bonnes pratiques et exemples

Description

Vous souhaitez sécuriser vos systèmes informatiques ? Consultez notre guide sur les évaluations de vulnérabilité, leur fonctionnement et les bonnes pratiques recommandées par les experts.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur