Les mises à jour s’effectuent automatiquement, mais personne ne peut le prouver

La question posée dans le questionnaire semble anodine : « Dans quels délais les mises à jour de sécurité critiques sont-elles installées, et comment le vérifiez-vous ? » Dans de nombreuses entreprises, la réponse honnête est la suivante : Windows se met à jour tout seul, le reste finit par se faire, et il n’y a aucun moyen de le prouver. C’est précisément sur ce point que les audits des fournisseurs échouent le plus souvent, bien plus qu’en raison d’un manque de technologie.

Le plus regrettable, c’est que l’entreprise est souvent mieux préparée qu’elle ne peut le prouver. Les systèmes sont à jour, mais personne ne peut dire à quel point, depuis quand, sur combien d’appareils, ni quelles vulnérabilités ont été corrigées. Cet article explique ce que les auditeurs et les grands clients souhaitent réellement voir, quels rapports fournissent ces informations, en quoi les modules de correction des principaux fournisseurs diffèrent, et quelles sont les limites à connaître avant d’acheter.

Pourquoi les auditeurs s’enquièrent-ils en premier lieu de l’état des correctifs ?

Parce que les vulnérabilités non corrigées et connues du public comptent parmi les points d’entrée les plus courants — et parce que, contrairement à de nombreux autres facteurs, cet aspect peut être vérifié de manière objective. Un auditeur ne peut pas évaluer dans quelle mesure votre personnel sait reconnaître une tentative de phishing. En revanche, il peut demander depuis combien de temps la plus ancienne vulnérabilité critique non corrigée figure dans votre inventaire — et ce chiffre en dit long sur l’organisation dans son ensemble.

De plus, ce sujet figure dans pratiquement toutes les réglementations. La version 2022 de la norme ISO 27001 mentionne la gestion des vulnérabilités techniques comme un point de contrôle distinct à la section 8.8. La directive NIS 2 cite explicitement la gestion et la divulgation des vulnérabilités parmi les catégories de mesures requises. Et la norme minimale suisse en matière de TIC inclut la gestion des vulnérabilités dans les fonctions « Identifier » et « Protéger ». Quiconque élabore un questionnaire s’appuie sur ces sources — ce qui explique pourquoi les questions se ressemblent tant.

Faut-il procéder à la mise à jour, ou suffit-il d’en apporter la preuve ?

Les deux, mais c’est la preuve qui est vérifiée. C’est là que la plupart des organisations sous-estiment le problème. Un auditeur ne peut pas voir si vos appareils sont à jour ; il ne peut voir que ce que vous lui présentez.

En règle générale, quatre éléments sont requis. Premièrement, une politique écrite précisant les responsabilités et les délais en fonction de la gravité — par exemple, les vulnérabilités critiques doivent être corrigées dans un délai de quatorze jours. Deuxièmement, des rapports démontrant que des analyses de vulnérabilité sont effectuées régulièrement, avec un calendrier précis. Troisièmement, un système de suivi de la découverte à la résolution, indiquant qui a fait quoi et quand. Quatrièmement, une politique d’exception documentée pour tout ce qui ne peut pas être corrigé.

La plainte la plus courante est d’ordre spécifique : l’organisation marque une vulnérabilité comme résolue sans avoir techniquement vérifié que le correctif a bien été appliqué. Une case cochée sur une liste ne constitue pas une preuve — un nouveau scan qui ne détecte plus la vulnérabilité, en revanche, en est une.

Répondre correctement aux questionnaires de sécurité des principaux clients
permet de déterminer quels éléments de ces questionnaires peuvent être étayés par un logiciel de gestion des terminaux et lesquels doivent être vérifiés par des mesures organisationnelles.

Les mises à jour automatiques de Windows ne suffisent-elles pas ?

Pour le système d’exploitation, oui ; pour le reste, non — et ce « reste » constitue la plus grande surface d’attaque. Les mises à jour automatiques de Microsoft couvrent Windows et les applications Microsoft. Elles ne couvrent pas tout le reste généralement installé sur un poste de travail : les logiciels de lecture de PDF, les navigateurs autres qu’Edge, les outils d’archivage, les environnements d’exécution, les logiciels de maintenance à distance et les applications spécifiques à un secteur d’activité.

Ce sont précisément ces programmes qui sont répertoriés dans le questionnaire sous la rubrique « applications tierces », et ce sont précisément ceux-là qui sont le plus souvent obsolètes dans la pratique, car personne ne s’en occupe individuellement. Un module de correctifs les gère de manière centralisée et, ce faisant, offre un avantage indirect qui compte vraiment : une liste précise des logiciels effectivement utilisés. Cet inventaire est la première pièce jointe requise pour la plupart des audits. Il y a un deuxième point à prendre en compte : les mises à jour automatiques ne peuvent pas être contrôlées. Quiconque doit prouver qu’un correctif a été installé dans un délai précis a besoin d’un calendrier et d’un rapport — et non d’un mécanisme qui s’exécute de lui-même à un moment donné.

Quelle est la différence entre la gestion des vulnérabilités et la gestion des correctifs ?

La gestion des vulnérabilités identifie et évalue les vulnérabilités ; la gestion des correctifs les résout. Cette distinction n’est pas seulement d’ordre sémantique : c’est la raison pour laquelle certaines questions du questionnaire ne peuvent pas trouver de réponse en utilisant uniquement un module de correctifs.

Le processus comporte quatre étapes : identifier les logiciels installés et les vulnérabilités connues qu’ils présentent ; évaluer la gravité et l’exploitabilité de ces vulnérabilités au sein de votre propre environnement ; y remédier, généralement à l’aide d’un correctif ; et vérifier que la correction a été efficace. La plupart des produits de cette catégorie couvrent ces quatre étapes, c’est pourquoi on les appelle souvent « gestion des vulnérabilités et des correctifs ».

Cette distinction prend toute son importance lorsqu’aucun correctif n’est disponible, soit parce que l’éditeur n’en a pas encore publié, soit parce que le logiciel est en fin de cycle de vie. Dans de tels cas, chaque ensemble de lignes directrices exige une mesure alternative et une décision — et non pas simplement l’inaction. C’est précisément pour cette raison que la phase d’évaluation est nécessaire.

Quels délais dois-je fixer pour les vulnérabilités critiques ?

Un délai que vous pouvez respecter. Cela semble évident, mais c’est la seule règle sensée : un délai de sept jours régulièrement non respecté fait pire lors d’un audit qu’un délai de trente jours respecté. Vous avez pris un engagement et vous ne l’avez pas tenu.

Il est courant de hiérarchiser les délais en fonction de la gravité, avec des délais différents pour les failles critiques, élevées et moyennes. Cependant, la gravité seule est un indicateur peu fiable. La classification gagne en pertinence lorsque deux facteurs supplémentaires sont pris en compte : le fait que la vulnérabilité soit déjà activement exploitée et le fait que le système affecté soit accessible depuis Internet. Une vulnérabilité de gravité moyenne sur un serveur connecté à Internet — pour laquelle des outils d’attaque existent déjà — est plus urgente qu’une vulnérabilité critique sur un système de test isolé.

Intégrez cette logique dans votre politique. Un auditeur qui constate que vous établissez vos priorités en fonction de l’exploitabilité et de l’exposition plutôt que strictement en fonction du score considérera cela comme un processus abouti — et acceptera des délais plus longs pour la partie non critique.

De quels rapports spécifiques ai-je besoin ?

Cinq rapports couvrent la grande majorité des questionnaires et audits, et tous les cinq proviennent de la console de gestion, et non d’un tableur géré en interne.

Premièrement, la liste d’inventaire : quels appareils sont gérés et quels logiciels y sont installés. Deuxièmement, le rapport sur les correctifs manquants, classés par niveau de gravité — ce rapport répond à la question de l’état actuel. Troisièmement, le même rapport avec des informations sur l’ancienneté, c’est-à-dire depuis combien de temps une vulnérabilité est exposée ; c’est l’indicateur qu’un auditeur utilise pour évaluer votre respect des délais. Quatrièmement, la liste des installations ayant échoué, car un correctif qui ne s’est pas installé correctement ne sera jamais détecté sans ce rapport. Cinquièmement, la synthèse des correctifs intentionnellement exclus, accompagnée des raisons de leur exclusion.

Tous ces rapports présentent deux caractéristiques qui font défaut à un tableau tenu à la main : une date et un périmètre. Le rapport n’indique pas seulement que quatre-vingt-douze appareils sont à jour, mais aussi qu’un total de quatre-vingt-quatorze sont gérés. C’est précisément cette différence qui fait toute la différence.

Que faire des systèmes qui ne peuvent pas être mis à jour ?

Vous les consignez en tant qu’exceptions — en précisant la raison, une solution de contournement, un délai et l’autorisation correspondante. Il s’agit d’une procédure reconnue et non d’un aveu de faiblesse. Ce qui n’est pas acceptable, c’est de ne pas mentionner du tout les systèmes concernés.

Parmi les exemples typiques, on peut citer un système de contrôle de machine dont le fabricant n’autorise pas les versions plus récentes, une application spécifique à un secteur d’activité qui nécessite un environnement d’exécution obsolète, ou encore un système hérité qui doit rester en service pour des raisons contractuelles. Les mesures correctives possibles comprennent l’isolation du réseau, la restriction des droits d’accès, le verrouillage de l’application sur le système concerné ou une surveillance renforcée.

Il est important de fixer un délai. Une exception sans date d’expiration sera signalée lors du prochain audit, car elle indique que personne ne surveille plus la situation. Fixez une date à laquelle la décision devra être réexaminée, même s’il est prévisible que le résultat sera le même.

En quoi les modules de correctifs des éditeurs diffèrent-ils ?

Les modules qui mettent à jour de manière centralisée les systèmes d’exploitation et les applications tierces et fournissent des rapports sur ces mises à jour sont comparables. Kaspersky propose sa solution « Vulnerability and Patch Management » à la fois comme produit autonome et comme module complémentaire aux suites existantes ; elle est donc abordée séparément ci-dessous.

Concernant les champs ouverts et restreints : sous Linux, Bitdefender ne met pas à jour les applications installées en dehors du gestionnaire de paquets et n’installe automatiquement que les correctifs signés numériquement ; pour tous les autres, une intervention manuelle est nécessaire, ce dont vous devez tenir compte dans le processus. Pour ESET, les informations concernant les identifiants CVE par correctif et le cache local ne sont pas disponibles avec le même niveau de détail et doivent donc être incluses dans la proposition. Pour Avast et AVG, il est explicitement indiqué que les mises à jour de sécurité étendues de Microsoft ne sont pas prises en charge — un élément à prendre en compte pour toute organisation exploitant un système au-delà de la fin normale du support.

Quel produit convient à quel environnement ?

Pour les environnements Windows purs qui n’utilisent pas encore de suite professionnelle proposée par l’un des principaux éditeurs, les produits autonomes constituent l’option la plus rapide : Avast Business Patch Management ⧉ et AVG Patch Management Business Edition ⧉. Ces deux solutions vous permettent de planifier des analyses quotidiennes, hebdomadaires ou mensuelles, d’afficher les correctifs manquants avec leur niveau de gravité et leur date de publication, et d’exclure des éditeurs ou des applications spécifiques. Pour économiser la bande passante, la distribution est gérée par un périphérique sélectionné sur le réseau. La limite est claire : Windows uniquement ; aucun autre système d’exploitation.

Si vous utilisez déjà GravityZone, vous pouvez ajouter Bitdefender GravityZone Patch Management ⧉ en tant que module complémentaire. Il prend en charge Windows, Linux et macOS, affiche l’identifiant CVE de chaque correctif, permet de bloquer des correctifs individuels s’ils perturbent un flux de travail et peut reporter le redémarrage requis. Pour la distribution au sein de votre propre réseau, un appareil jouant le rôle de relais peut également être configuré comme cache.

Avec ESET, ce module fait partie de l’offre par niveau. Il est inclus à partir de la version ESET PROTECT Complete ⧉ ainsi que dans ESET PROTECT Elite ⧉, qui comprend également le composant « Détection et réponse ». Pour les niveaux « Entry » et « Advanced », il peut être ajouté en tant que fonctionnalité distincte. Il couvre Windows, Linux et macOS, y compris les applications tierces, et cette fonctionnalité peut également être étendue aux serveurs, à condition qu’ils exécutent les dernières versions des produits serveur ESET correspondants.

Kaspersky propose les deux options suivantes : Kaspersky Vulnerability and Patch Management ⧉ en tant que produit autonome et Kaspersky Vulnerability and Patch Management en tant que module complémentaire ⧉ pour compléter une offre Kaspersky existante. L’option qui vous est proposée dépend du produit de base et doit être précisée avant de passer commande.

Base, Base Plus, Module complémentaire ou Renouvellement : signification de ces termes.
Explique comment interpréter les noms des suites disponibles sur le marché et lesquels d’entre eux nécessitent une licence existante.

Est-ce que je dispose peut-être déjà du module de correctifs ?

C’est possible, et il vaut mieux vérifier avant de passer commande. Plusieurs éditeurs ont intégré la gestion des correctifs dans leurs offres haut de gamme au lieu de la vendre séparément.

Chez Kaspersky, la gestion des correctifs est incluse dans le niveau Next EDR Optimum ; chez ESET, elle est incluse à partir de PROTECT Complete ; et ThreatDown Advanced ⧉ l’inclut également dans son offre groupée. Toute personne disposant déjà d’une licence pour l’un de ces niveaux n’a pas besoin d’un produit supplémentaire ; il lui suffit d’activer et de configurer la fonctionnalité — ce qui, dans la pratique, est étonnamment souvent négligé, car personne ne se rend compte qu’elle est incluse.

À l’inverse, chez Bitdefender, la gestion des correctifs n’est incluse dans aucun niveau de forfait, mais constitue systématiquement un module complémentaire payant. Une offre GravityZone qui n’inclut pas cet élément ne répond pas aux critères du questionnaire.

Quels sont les pièges à éviter lors d’un achat ?

Il y en a trois, qui ne sont souvent remarqués qu’après avoir passé commande.

Le premier concerne ESET : selon le fabricant, la gestion des vulnérabilités et des correctifs n’est pas disponible dans la version locale de la console de gestion, mais nécessite l’utilisation de la console cloud. Les organisations qui choisissent délibérément de gérer leurs systèmes en interne — par exemple, en raison d’exigences spécifiques à leur emplacement — ne peuvent pas utiliser cette fonctionnalité dans ce contexte. Il ne s’agit pas d’un détail mineur, mais d’une décision fondamentale qui doit être prise avant l’achat.

Le deuxième point concerne la liste des logiciels. Chaque module ne met à jour que ce qui figure dans son catalogue. Ces catalogues sont exhaustifs et sont continuellement enrichis, mais ils ne couvrent jamais tout. Bitdefender publie une liste téléchargeable des éditeurs et produits pris en charge, mise à jour chaque mois. Avant l’achat, vérifiez si vos applications les plus importantes y figurent : les logiciels spécifiques à un secteur d’activité, en particulier, y sont rarement répertoriés et doivent donc être gérés manuellement, ce que vous devrez documenter séparément.

Le troisième point concerne les serveurs. Un module de correctifs qui ne couvre que les postes de travail ne répond que partiellement à la question du questionnaire, puisque celle-ci porte sur l’ensemble de l’infrastructure. Précisez si les licences serveur incluent les mêmes fonctionnalités et si des éléments distincts sont nécessaires pour celles-ci.

Protection des serveurs, Exchange et serveurs de fichiers : pourquoi les licences pour terminaux ne suffisent
pas. Cet article explique pourquoi les serveurs nécessitent leurs propres licences et produits, et quels rôles supplémentaires doivent être couverts.

Comment gérer les redémarrages ?

Privilégiez les fenêtres de maintenance planifiées plutôt que les demandes ponctuelles. Les redémarrages sont la cause de l’échec de la gestion des correctifs dans de nombreuses organisations : personne ne souhaite redémarrer le serveur pendant les heures de travail, et il n’y a personne le soir.

Les modules résolvent ce problème grâce à deux mécanismes. Premièrement, l’analyse peut être dissociée de l’installation : les analyses s’exécutent quotidiennement, tandis que les installations ont lieu à une heure programmée. Deuxièmement, le redémarrage peut être reporté de sorte que le correctif soit installé mais ne prenne effet qu’au prochain redémarrage régulier.

En matière de vérification, un point est crucial mais souvent négligé : un correctif qui a été installé mais qui n’est pas encore actif ne comble pas la vulnérabilité. Si votre rapport comptabilise ces cas comme résolus, vous vérifiez un état qui n’existe pas. Par conséquent, définissez la durée pendant laquelle un redémarrage en attente peut rester ouvert, et traitez tout cas dépassant cette limite comme une vulnérabilité ouverte.

En quoi la gestion des correctifs facilite-t-elle le respect des obligations de déclaration en Suisse ?

À compter du 1er avril 2025, les exploitants d’infrastructures critiques doivent signaler les cyberattaques à l’Office fédéral de la cybersécurité dans les 24 heures suivant leur découverte, conformément à la loi révisée sur la sécurité de l’information et à l’ordonnance sur la cybersécurité ; les informations manquantes peuvent être fournies dans un délai de 14 jours. Cette obligation s’applique aux agences gouvernementales et aux organisations telles que définies à l’article 74b de la loi sur la sécurité de l’information (ISG) ; des exceptions existent pour les petites organisations et les incidents ayant des répercussions mineures.

L'état des correctifs ne joue aucun rôle direct dans le rapport lui-même. Cependant, il revêt une importance capitale immédiatement après, notamment pour déterminer comment l'attaquant a obtenu l'accès. S'il s'avère qu'une vulnérabilité connue depuis des mois et pouvant faire l'objet d'un correctif a été exploitée, cela présente un scénario différent de celui d'une attaque via une vulnérabilité inconnue au moment de l'incident. Un rapport documentant l’état des correctifs du système affecté au moment des faits constitue donc l’un des documents les plus précieux qui soient — à condition qu’il ait été généré et conservé avant l’incident.

Ce que la gestion des correctifs ne fait pas : elle ne détermine pas si votre organisation est soumise à des obligations de déclaration, elle ne détecte pas une attaque en cours et elle ne remplace pas une responsabilité désignée en matière de déclaration.

Quelles sont les exigences de la directive NIS 2 concernant les vulnérabilités ?

La directive mentionne la gestion et la divulgation des vulnérabilités parmi les catégories de mesures que les organisations concernées doivent mettre en œuvre. Elle ne prescrit aucun logiciel spécifique ni de délai concret : ce qui est exigé, c’est une procédure dont l’application peut être démontrée.

Cette exigence est prise en charge par les analyses, la hiérarchisation et les rapports générés par un module de gestion des correctifs. Les aspects organisationnels ne sont pas couverts : la définition écrite des délais, l’attribution des responsabilités, la gestion des signalements externes concernant les vulnérabilités découvertes, ainsi que l’évaluation régulière de l’efficacité même de la procédure. Aucun produit ne peut répondre à ces exigences.

Les organisations tenues de se conformer à la fois aux exigences suisses et européennes sont confrontées à deux ensembles de réglementations qui diffèrent en termes de délais et de terminologie.

Une comparaison des obligations en matière de cybersécurité en Suisse et dans l’UE
compare les exigences suisses en matière de signalement avec celles de la directive NIS 2 et met en évidence leurs différences.

Que ne couvre pas un module de correctifs ?

Tout ce qui n’est pas un système d’exploitation ou une application installée — et cela représente plus que vous ne le pensez.

Ne sont pas couverts les micrologiciels des périphériques réseau, des pare-feu, des points d’accès, des imprimantes et des systèmes NAS. Or, ce sont précisément ces périphériques qui sont directement connectés à Internet et dont les vulnérabilités sont particulièrement souvent exploitées. Sont également exclus les systèmes de contrôle des machines, les services cloud dont le fournisseur gère les mises à jour, ainsi que les logiciels ayant atteint la fin de leur cycle de vie et pour lesquels il n’existe tout simplement plus de correctifs disponibles.

Pour ces domaines, vous aurez besoin d’un deuxième processus, généralement manuel, avec sa propre liste et son propre calendrier. Quiconque coche la case du questionnaire indiquant que tous les systèmes sont intégrés à la gestion des correctifs — alors que les pare-feu et les périphériques NAS sont gérés séparément — fournit des informations qui ne résisteront pas à un examen approfondi.

Comment se lancer en trente jours ?

Au cours de la première semaine, établissez une visibilité : activez ou procurez-vous le module, intégrez tous les périphériques et effectuez un premier scan complet. L’expérience montre que les résultats sont souvent déconcertants — et c’est précisément pour cela qu’ils sont précieux —, car ils révèlent pour la première fois l’inventaire réel.

Au cours des deuxième et troisième semaines, traitez le retard accumulé, en commençant par tout ce qui est accessible depuis Internet, et documentez simultanément les directives : qui est responsable, quels sont les délais applicables en fonction de la gravité, quand effectuer un scan, quand installer les mises à jour et comment les exceptions sont approuvées. Une page suffit ; il suffit qu’elle soit datée et approuvée.

Au cours de la quatrième semaine, vous générez la première série de rapports et vous les archivez. C’est précisément ce rapport archivé et daté qui sert de preuve que les gens réclament — et dès que vous commencez à répéter ce processus chaque mois, un instantané se transforme en un historique vérifiable. C’est là la véritable différence entre une entreprise qui corrige ses vulnérabilités et une autre capable de le prouver.