Relier les vulnérabilités publiées à son parc réel

Des dizaines de vulnérabilités sont publiées chaque semaine, concernant des logiciels, des équipements ou des services utilisés à des degrés divers par la quasi totalité des organisations. Les travaux de l'Observatoire de l'Intelligence Économique montrent que l'enjeu, pour une équipe de veille, n'est plus de repérer ces publications, largement accessibles, mais de déterminer lesquelles concernent réellement son propre parc et ses fournisseurs, parmi un volume qui dépasse largement la capacité de traitement humain.

Le volume comme premier obstacle

Le nombre de vulnérabilités publiées chaque année a considérablement augmenté, porté par la multiplication des logiciels, des bibliothèques et des services interconnectés. Cette croissance rend illusoire l'idée de lire individuellement chaque publication pour juger de sa pertinence. Une organisation qui tenterait cet exercice consacrerait l'essentiel de son temps de veille à des vulnérabilités qui ne la concernent pas, au détriment du traitement rapide de celles qui l'exposent réellement.

Ce volume impose un tri préalable, fondé non pas sur la gravité affichée d'une vulnérabilité, mais sur sa pertinence pour le parc effectivement déployé. Une vulnérabilité jugée critique par sa description générale peut n'avoir aucun impact si le composant concerné n'est pas utilisé en interne, tandis qu'une vulnérabilité d'apparence mineure peut exposer directement l'organisation si elle touche un composant central de son infrastructure.

Ce volume varie aussi fortement selon les familles de composants concernées. Certaines catégories de logiciels concentrent une part disproportionnée des publications, tandis que d'autres en reçoivent rarement, ce qui justifie de pondérer l'attention portée à chaque publication par la nature du composant plutôt que par un traitement uniforme de l'ensemble des annonces reçues chaque semaine.

L'inventaire, condition préalable à tout tri

Relier un identifiant de vulnérabilité à une exposition réelle suppose de disposer, en amont, d'un inventaire à jour des composants utilisés : logiciels, versions précises, bibliothèques intégrées et services fournis par des tiers. Sans cet inventaire, chaque publication de vulnérabilité oblige à une vérification manuelle, longue et sujette à l'erreur, pour déterminer si l'organisation est concernée.

L'Observatoire de l'Intelligence Économique souligne que cet inventaire doit descendre jusqu'au niveau des bibliothèques intégrées dans les logiciels utilisés, et pas seulement aux logiciels eux-mêmes. Une application interne peut ne présenter aucune vulnérabilité connue à son propre niveau, tout en intégrant une bibliothèque tierce qui, elle, fait l'objet d'une publication récente. Cette granularité, difficile à maintenir manuellement, conditionne pourtant la fiabilité de tout le dispositif de tri qui en dépend.

La mise à jour de cet inventaire pose une difficulté organisationnelle autant que technique. Elle suppose une collaboration régulière entre les équipes qui déploient de nouveaux composants et celles qui assurent la veille sur les vulnérabilités, une coordination qui fait souvent défaut lorsque ces deux fonctions relèvent de services distincts sans processus formel de communication entre eux.

La dimension fournisseur, un angle mort fréquent

L'exposition d'une organisation ne se limite pas à ses propres systèmes. Une part importante du risque transite par les fournisseurs et prestataires qui accèdent à des données ou à des systèmes internes, ou qui fournissent des composants intégrés aux outils utilisés en interne. Une vulnérabilité publiée sur un produit d'un fournisseur, sans lien apparent avec les systèmes propres de l'organisation, peut néanmoins constituer un point d'entrée si ce fournisseur dispose d'un accès à des ressources internes.

Ce recoupement suppose de maintenir une cartographie des fournisseurs comparable, dans sa logique, à l'inventaire interne : quels prestataires, avec quels accès, utilisant quels composants connus. L'Observatoire de l'Intelligence Économique relève que cette cartographie reste, dans de nombreuses organisations, incomplète ou obsolète, ce qui laisse un angle mort persistant entre la veille sur les vulnérabilités et la connaissance réelle de la chaîne de fournisseurs.

Cet angle mort s'aggrave lorsque la chaîne de fournisseurs comporte plusieurs niveaux. Un prestataire direct peut lui-même dépendre d'un sous traitant technique, dont les composants ne sont jamais mentionnés dans les échanges contractuels habituels. Une vulnérabilité affectant ce sous traitant de second niveau reste alors invisible pour l'organisation qui en dépend indirectement, sauf si le prestataire direct communique explicitement sur ce point, ce qui n'est pas toujours systématique ni rapide.

Cette difficulté se double d'un enjeu contractuel : peu d'accords avec les fournisseurs prévoient une obligation claire de signalement rapide en cas de vulnérabilité découverte sur les composants qu'ils fournissent, ce qui laisse l'organisation cliente dépendante de la seule vigilance et de la bonne volonté de ses prestataires pour être informée à temps.

Prioriser plutôt que traiter à égalité

Une fois le tri effectué, toutes les vulnérabilités pertinentes ne demandent pas le même traitement dans le même délai. La priorisation repose sur plusieurs critères combinés : la criticité du système concerné pour l'activité de l'organisation, l'exposition de ce système à un accès externe, et l'existence connue ou non d'une exploitation active de la vulnérabilité en dehors d'un cadre théorique.

Cette priorisation évite l'écueil inverse au sous traitement : consacrer un temps disproportionné à des vulnérabilités qui, bien que réelles et pertinentes pour le parc, concernent des systèmes secondaires ou peu exposés, au détriment d'une réaction plus rapide sur les composants réellement critiques. Un tri qui ne débouche pas sur une hiérarchie claire des priorités ne réduit que partiellement la charge que représente le volume initial de publications.

Cette hiérarchie gagne à être révisée périodiquement plutôt que figée une fois pour toutes. Un système jugé secondaire à un instant donné peut voir sa criticité augmenter à mesure que son usage se développe au sein de l'organisation, ce qui impose de réévaluer régulièrement la place de chaque composant dans l'échelle de priorité retenue.

Le délai entre publication et action

Le temps qui sépare la publication d'une vulnérabilité de sa correction effective constitue une fenêtre pendant laquelle l'exposition reste ouverte. Ce délai dépend de plusieurs facteurs : la rapidité avec laquelle l'organisation identifie que la vulnérabilité la concerne, la disponibilité d'un correctif du fournisseur concerné, et la capacité opérationnelle à déployer ce correctif sans perturber les systèmes en production.

Réduire la première partie de ce délai, celle qui va de la publication à l'identification de la pertinence pour l'organisation, dépend directement de la qualité du lien entre les publications de vulnérabilités et l'inventaire interne. C'est sur ce segment précis que se concentre l'essentiel du gain possible pour une équipe de veille, la partie suivante, correction et déploiement, relevant davantage des équipes techniques que de la veille elle-même.

Ce délai varie aussi selon la nature du composant concerné. Un logiciel largement répandu bénéficie souvent d'un correctif publié rapidement par son fournisseur, tandis qu'un composant plus spécifique ou moins entretenu peut rester exposé plus longtemps, faute d'une réponse aussi rapide de la part de l'organisation qui le maintient.

Les limites de cette approche

Un inventaire, aussi précis soit il, ne capture jamais l'intégralité d'un parc en temps réel. Des composants ajoutés récemment, des usages non déclarés par certaines équipes, ou des outils utilisés en dehors des canaux officiels échappent souvent à cette cartographie, créant des zones d'ombre que la veille sur les vulnérabilités ne peut combler à elle seule. Ces zones nécessitent un travail complémentaire, du côté de la gouvernance interne des systèmes, qui dépasse le seul périmètre de la veille.

De même, l'absence de vulnérabilité publiée sur un composant ne garantit jamais son absence réelle. Le silence sur une publication reflète parfois un manque de recherche sur ce composant précis plutôt qu'une sécurité avérée, ce qui doit tempérer toute conclusion tirée d'un inventaire qui ne présenterait, à un instant donné, aucune correspondance avec les publications récentes.

Enfin, la priorisation elle-même comporte une part de jugement qui ne se réduit pas entièrement à un calcul automatique. Deux organisations disposant du même inventaire et confrontées à la même publication peuvent légitimement lui accorder une urgence différente, selon leur tolérance au risque et leurs contraintes opérationnelles propres. Ce jugement final reste une responsabilité humaine, que l'outillage vient éclairer sans jamais s'y substituer complètement.

www.newscore.fr relie les identifiants de vulnérabilités publiées à l'inventaire interne et aux fournisseurs suivis, et détecte ainsi les publications qui exposent réellement une organisation, plutôt que l'ensemble des vulnérabilités qui paraissent chaque semaine.

Questions fréquentes

Faut il traiter chaque vulnérabilité selon un score de gravité générique ? Non, ce score, utile comme point de départ, doit être ajusté par le contexte réel de l'organisation : exposition du système concerné, criticité de son usage, et existence d'une exploitation active connue.

Comment maintenir un inventaire à jour sans y consacrer un temps excessif ? En privilégiant une mise à jour continue, alimentée par les changements réels de configuration, plutôt qu'un inventaire figé reconstitué périodiquement de façon manuelle, toujours en décalage avec la réalité du parc.

Les fournisseurs doivent ils être intégrés à ce même inventaire ? Oui, sous une forme adaptée, en recensant leurs accès et les composants qu'ils fournissent, faute de quoi une part significative du risque réel échappe entièrement au dispositif de tri.

Une petite organisation a t elle besoin de ce type de dispositif ? Oui, dans une mesure proportionnée à son parc : même un inventaire simple, limité aux systèmes les plus critiques, réduit sensiblement le temps perdu sur des publications sans rapport avec son activité réelle.