Qu’est-ce qu’une vulnérabilité de sécurité informatique ?

Une faille est une faiblesse, pas une attaque

Une faille de sécurité, également appelée vulnérabilité, est une faiblesse susceptible d’être exploitée. Elle peut se trouver dans un logiciel non corrigé, un équipement obsolète, une configuration, un mécanisme d’authentification ou une procédure interne. Le catalogue Vulnerability-Lookup exploité par le CIRCL illustre la partie la plus visible du sujet : les vulnérabilités techniques publiquement recensées. Toutes les faiblesses ne reçoivent toutefois pas un identifiant public.

Il faut distinguer trois notions. La vulnérabilité est le point faible. La menace est ce qui pourrait l’exploiter, par exemple un attaquant ou un logiciel malveillant. L’incident est l’événement qui affecte effectivement la confidentialité, l’intégrité ou la disponibilité d’un système. Cette distinction évite d’annoncer une compromission dès qu’un défaut est découvert.

Pourquoi toutes les failles n’ont-elles pas la même priorité ?

Une note de gravité technique ne suffit pas à décider. Une vulnérabilité critique sur un serveur isolé et éteint peut être moins urgente qu’une faiblesse moins sévère sur un service exposé à Internet. L’évaluation doit donc tenir compte de l’exploitation connue, de l’exposition, des privilèges accessibles, des données traitées et des conséquences possibles sur l’activité. Le catalogue européen des vulnérabilités exploitées de l’ENISA et le service du CIRCL aident à vérifier l’existence d’informations publiques ; ils ne remplacent pas l’analyse du contexte propre à l’entreprise.

Comment une entreprise doit-elle réagir ?

La première étape consiste à savoir quels matériels, logiciels et services sont réellement utilisés. Sans inventaire, il est impossible de déterminer si une alerte concerne l’entreprise. Il faut ensuite suivre les avis des éditeurs et des autorités, tester les correctifs lorsque le risque opérationnel le justifie, les déployer selon une priorité documentée et vérifier le résultat. Le Guide d’hygiène informatique de l’ANSSI recommande notamment de maintenir les composants à jour, de maîtriser les comptes et de protéger les sauvegardes.

Lorsqu’un correctif ne peut pas être appliqué immédiatement, une mesure compensatoire peut réduire l’exposition : désactiver une fonction, restreindre l’accès, isoler l’équipement ou renforcer la surveillance. Cette mesure doit avoir un responsable et une échéance ; elle ne transforme pas un report indéfini en correction.

Que faut-il vérifier après la correction ?

Installer un correctif ne clôt pas automatiquement le sujet. Il faut confirmer que la version attendue est active, que le service fonctionne et qu’aucun signe d’exploitation antérieure n’est visible. Les journaux peuvent servir à cette vérification : l’ANSSI rappelle qu’ils sont utiles aussi bien pour détecter un incident que pour en reconstituer le déroulement.

Un cas : une faille chez un tiers, des victimes qui ne l’avaient jamais installée

Le 31 mai 2023, l’éditeur Progress Software publie un avis critique sur MOVEit Transfer, un logiciel de transfert de fichiers d’entreprise. La faille, référencée CVE-2023-34362, est une injection SQL : elle permet à un attaquant non authentifié d’atteindre la base de données du serveur.

L’avis conjoint du FBI et de la CISA, publié le 7 juin 2023, établit que le groupe CL0P exploitait déjà la faille le 27 mai, soit quatre jours avant l’annonce publique. Les attaquants déposaient un composant nommé LEMURLOOT pour extraire les fichiers hébergés, puis réclamaient un paiement.

Ce qui intéresse une PME luxembourgeoise n’est pas MOVEit. C’est qu’une grande partie des organisations touchées ne l’avaient jamais installé. Elles ont été atteintes parce qu’un prestataire l’utilisait pour leur compte : gestionnaire de paie, cabinet comptable, assureur, éditeur métier. Le fichier du personnel d’une entreprise de vingt salariés pouvait se trouver sur un serveur dont elle ignorait l’existence.

Trois enseignements s’en dégagent, et aucun ne demande de compétence technique :

• Une faille se subit aussi par délégation. Le périmètre à surveiller n’est pas celui des machines que l’on possède, mais celui des données que l’on a confiées.
• Le délai de correction se compte en heures, pas en semaines. Entre l’avis et l’exploitation de masse, il s’est écoulé quelques jours. L’avis du FBI et de la CISA le dit sans détour : corriger à temps est l’une des mesures les plus efficaces et les moins coûteuses qu’une organisation puisse prendre.
• Une faille exploitée avant sa publication existe. Cela ne dispense pas de corriger ; cela explique pourquoi la détection et les sauvegardes comptent autant que le correctif.

Ce que doit décider une PME

Les décisions ci-dessous ne sont pas techniques. Elles se prennent en réunion de direction, elles s’écrivent, et elles ont un responsable.

• Qui reçoit les avis de sécurité, et à quelle adresse ? Une alerte envoyée à une boîte relevée une fois par semaine n’est pas une alerte. Au Luxembourg, le CIRCL diffuse ces avis gratuitement.
• Quel délai maximal accepte-t-on entre un avis critique et sa correction ? Écrire « 72 heures pour ce qui est exposé à Internet » vaut mieux que de ne rien écrire. Un délai non fixé devient un délai infini.
• Qui peut décider d’arrêter un service pour le corriger ? Sans cette réponse, la correction attend la personne qui n’ose pas interrompre la production.
• Quels prestataires détiennent nos données, et comment nous préviennent-ils ? Cette question se pose à la signature du contrat, pas le jour de l’incident. C’est elle qui manquait à la plupart des victimes de MOVEit.
• Que fait-on lorsqu’un correctif ne peut pas être appliqué ? La mesure de contournement doit avoir un responsable et une date de fin. Sans échéance, elle devient l’état normal.

Sources

Liens vérifiés le 28 septembre 2026.

• FBI et CISA, avis conjoint AA23-158A, 7 juin 2023, mis à jour le 16 juin 2023 : cisa.gov.
• Progress Software, avis de sécurité MOVEit Transfer, 31 mai 2023 : community.progress.com.
• CISA, catalogue des vulnérabilités exploitées connues : cisa.gov.
• ENISA, base européenne des vulnérabilités : euvd.enisa.europa.eu.
• CIRCL, Vulnerability-Lookup : vulnerability.circl.lu.
• CIRCL, centre de réponse aux incidents du Luxembourg : circl.lu.

La détection continue est développée dans l’article Qu’est-ce qu’un SOC ?. Pour comprendre ce qu’un capteur réseau peut — et ne peut pas — observer, consultez Sonde cybersécurité : définition, utilité et limites.