L’idée d’associer les résultats d’une analyse de vulnérabilités (réalisée a priori) aux alertes d’un IPS/IDS en temps réel n’est pas neuve. « Il y a cinq ans déjà un client nous demandait une telle corrélation entre ses scans de vulnérabilités et ses IPS. Sa démarche était cependant plutôt de savoir adresser au mieux les vulnérabilités restantes : celles dont il connaît l’existence mais qu’il ne peut pas corriger tout de suite. Il voulait savoir si celles-ci étaient exploitées », explique Joseph Graceffa, Directeur Technique et co-fondateur d’Advens.

L’autre objectif d’une telle corrélation est bien entendu aussi d’être en mesure de prioritiser les alertes de l’IPS/IDS : il n’y aucune raison, par exemple, qu’une attaque web spécifique à Microsoft IIS mais dirigée contre un serveur Apache bénéficie de la même attention qu’une autre qui, elle, présente tous les pré-requis pour réussir (application, version).

« Corrélation » est le terme-clé ici. Et lorsqu’on parle de corrélation, les SIEM viennent immédiatement à l’esprit. Mais il s’agit de projets souvent structurants, et si l’objectif est uniquement d’affiner la pertinence des alertes de l’IPS, la solution d’une corrélation ad-hoc peut sembler tentante.

Sa mise en oeuvre est toutefois moins simple qu’il n’y paraît. « Nous avons commencé par faire une corrélation simple à partir du code CVE que l’on retrouve à la fois dans les alertes de l’IPS et dans les rapports de vulnérabilités, mais cela n’était pas satisfaisant », poursuit Joseph Graceffa.

En effet, bien que CVE soit standard, toutes les vulnérabilités ne disposent pas obligatoirement de leur référence CVE. « Nous avons du y ajouter beaucoup d’autres règles, la lecture des bannières des applications, vérifier si le port attaqué est visible ou non par le scanner de vulnérabilités, etc… Cela a finalement demandé trois semaines de travail à plein temps pour un développeur passionné, et il faut vraiment être en mesure de bien comprendre le format des signatures Snort, les attaques, etc… », détaille Joseph Graceffa.

Une telle corrélation est bien entendu grandement facilitée si l’outil de Vulnerability Management (VM) expose une interface afin de favoriser l’intégration (QualysGuard et son API XML par exemple), ou si celle-ci est prise en charge via un accord entre les éditeurs des deux solutions (c’est par exemple l’un des axes de l’accord récent conclus par Qualys avec TippingPoint, et également avec Sourcefire, l’éditeur de Snort).

Mais pour autant qu’elle soit possible, une telle intégration est-elle toujours nécessaire, voire souhaitable ? « Cette corrélation avait du sens afin de palier aux faiblesses des IPS lorsqu’ils étaient directement issus d’une technologie IDS. C’était alors le moyen de limiter le nombre d’alertes. Mais il semble en fait plus logique de chercher à améliorer l’IPS dans ce cas », observe Jeremy D’Hoinne, Directeur Marketing produit chez Netasq.

Ce que confirme volontiers Joseph Graceffa : « Nous n’avons plus vraiment de demandes pour ça aujourd’hui. On sent vraiment que les clients sont passés à l’IPS et que celui-ci offre désormais un niveau de détection suffisant pour que ne se pose plus la question de la corrélation. Cela ne dispense pas bien entendu de rester très vigilant sur la gestion (du cycle de vie, ndlr) des vulnérabilités, mais il semble que les IPS suffisent la plupart du temps aux clients », confirme le Directeur technique.

Enterré, donc, le mariage IPS-VM ? Pas tout à fait. « Cela peut aider afin de déterminer quelles alarmes je vais traiter en premier. Corréler pour gagner du temps, oui. Corréler parce que l’IPS est trop sensible, non ! », nuance Jeremy D’Hoinne. Et c’est d’ailleurs ce que fait Netasq en associant au sein du moteur IPS une corrélation entre les attaques observées et les informations collectée passivement sur le réseau (qui utilise quel navigateur, quel logiciel et quelle version d’OS sont installées sur ce serveur, etc). « Cela permet pour chaque alerte de montrer dans la console d’administration quelle machine est visée et en quoi elle est vulnérable à cette attaque », poursuit Jeremy D’Hoinne. Pas question ici de supprimer des alertes inutiles, mais bien d’enrichir celles existantes. « Mais un client qui n’a pas les moyens d’être vigilant et réactif dans sa gestion des vulnérabilités pourra certes encore y gagner à corréler avec l’IPS », pondère Jospeh Graceffa.

Autre intérêt : l’IPS étant censé être en coupure du flux réseau, les administrateurs ont tout intérêt à être alertés rapidement lorsqu’une connexion à destination d’une ressource sensible vient d’être coupée, afin de gérer au mieux les inévitables faux positifs.

Une telle corrélation peut, enfin, aussi permettre de jeter un pont entre deux services qui ne se parlent habituellement pas : « Nous observons que chez nos clients, il y a véritablement l’IPS d’un côté – géré par les équipes réseau – et la VM de l’autre, gérée par le RSSI. Et ce dernier est surtout intéressé par connaître les vulnérabilités existantes et savoir si elles sont corrigées. Savoir exactement si et comment elles sont exploitées n’est pas de son ressort : le RSSI ne devrait pas, à mon avis, être dans le curatif », observe Joseph Graceffa.

Créer un lien automatique entre les deux, qui permettrait à l’administrateur de l’IPS de traiter en priorité les alertes qui ont du sens et du poids d’après la politique de sécurité et les choix du RSSI pourrait dans ces conditions s’avérer effectivement très utile.