Yann Le Borgne, Sourcefire : « L’architecture réseau, une des limites de la détection d'intrusions »

LeMagIT : quelles sont les principales difficultés pour construire un système de détection des attaques de l’ampleur de celui auquel travaille l’Anssi (Agence Nationale pour la Sécurité des Systèmes d’Information) ?

Yann Le Borgne : Il faut commencer par le besoin : détecter un certain nombre de choses. La première problématique consiste donc à identifier le besoin et les placements [pour les sondes de détection, NDLR] afférents pour une solution de type IDS [système de détection d'intrusion, NDLR]. Cela peut paraître simple mais peut vraiment ne pas l’être : cela dépend de la manière dont les SI à surveiller sont conçus logiquement et techniquement. De manière générale, les clients expriment le besoin de connaître [les tentatives d'intrusion, NDLR] – de savoir où se déroule éventuellement l’intrusion. Je vais prendre un exemple tout simple : quelqu’un qui dispose d’une application n-tiers va nous demander de détecter les intrusions le plus en amont possible mais, au moment de l’implémentation, va s’apercevoir que là où l’on sera le plus pertinent, c'est là où se trouve la donnée sensible [en aval, plutôt qu'en amont, NDLR].

LeMagIT : Il s’agit donc de ne pas de cantonner à une logique de protection périmétrique, mais d’aller au plus près des données sensibles, en profondeur ?

Y.L.B : Effectivement. C’est tout l’intérêt d’un système de détection : de ne pas reposer forcément et uniquement sur la détection d’une menace. C’est intéressant, mais un IDS n’est ni plus intelligent ni plus bête qu’un autre système : c’est une question de paramétrage et de gestion ; plus on est loin dans les couches applicatives, plus on peut, si l’on a raté une intrusion claire – exploit de vulnérabilité, typiquement –, travailler sur le comportemental et détecter un comportement ou une activité qui n’est pas standard [un flux de données incohérent avec les processus par exemple, NDLR]. C’est la capacité à détecter du flux malicieux ou bien s'appuyant sur des protocoles non standard, ou encore à détecter de l’encapsulation imprévue dans un flux HTTP. Des choses comme ça [conçues pour cacher des transactions, NDLR] qui échappent à l’analyse classique d’antivirus. Mais les deux sont complémentaires : la protection périmétrique et l’analyse des flux.

LeMagIT : N’a-t-on pas des points d’analyse particulièrement difficiles tels que l’accès via un VPN à sous-réseau pour un tiers partenaire ?

Y.L.B : Là, on n’a plus de visibilité. Mais là où l’outil d’IDS prend son sens, c’est pour vérifier que l’ensemble de ces procédures – de contrôle d’accès – sont respectées. Et, typiquement, quand on détermine ses ressources critiques, on a intérêt à placer l’outil de détection en aval des procédures de prévention.

LeMagIT : Est-ce que la limite, ce n’est pas l’architecture réseau historique ?

Y.L.B : Oui, parce que, comme je vous le disais au début, la difficulté, c’est de définir les placements (des sondes, NDLR) en fonction de son architecture. Dans ce sens, la limite, c’est effectivement que l’on arrive sur un existant et que certaines choses y sont possibles, d’autres pas. Les limites, typiquement, c’est le chiffrement plutôt qu’une infrastructure existante. On peut, par exemple, faire du mirroring [réplication en miroir, NDLR] des flux réseau pour brancher des dispositifs de surveillance. Ce ne serait pas pareil dans de la prévention d’intrusion – où l’on a de vraies limites techniques – mais dans la détection, la seule limite, c’est le chiffrement : lorsque l’on choisit de chiffrer, ce n’est pas pour mettre quelque chose au milieu qui va surveiller ce qui se passe... et casser toute la stratégie de sécurité que l’on a définie.

LeMagIT : Où, alors, voyez-vous une limite contraignante à la détection d’intrusions ?

Y.L.B : Elle est dans l’exploitation et l’analyse au jour le jour. Le risque étant de tourner quelque chose qui était censé être utile et démontrer l’efficacité des mesures de prévention, par exemple, en quelque chose qui n’est plus exploitable parce que l’on n’a pas choisi efficacement ses points de surveillance. La limite de l’IDS est là, dans l’exploitation de la solution. L’exploitant, celui qui configure l’outil, détermine un périmètre. Et s’il est trop étendu, qu’on lui demande de surveiller trop de choses, les événements remontant seront trop nombreux et deviendront impossibles à gérer. La limite, c’est donc de ne pas se projeter dans le contexte de ce qui doit être protégé.

C’est d’ailleurs un élément que nous avons intégré : la solution est configurée chez nos clients pour savoir ce qu’elle protège et, quand elle remonte un événement, elle est capable de le replacer dans son contexte – notamment technologique, pour ne pas remonter des événements ne concernant que des environnements Windows, alors que l’on travaille en environnement Linux par exemple.

LeMagIT : Quelles sont alors les limites de l’industrialisation de l’exploitation d’un IDS ?

Y.L.B : La limite, c’est donc de ne pas se projeter dans le contexte de ce qui doit être protégé. Quoiqu’il arrive, il y a un humain au bout. Aucune solution ne peut dire, dans un monde de détection, « voilà le seul et unique événement auquel il faut s’intéresser et qui représente une menace. » Nous utilisons une technologie d’analyse passive du réseau – d’autres préfèrent une analyse active, mais le réseau peut avoir changé entre deux analyses – qui remonte des événements. Cela suppose de travailler sur les remontées. Il peut y avoir des faux positifs dans le lot, mais pas de faux négatifs parce que l’information est temps réel. Et il est plus facile, à l’exploitation, de se dire « que l'on me remonte cinq événements et il faut que je les étudie », plutôt que « on me remonte deux événements mais, pour ce qui ne m’est pas remonté, j’ai un doute. » Quel que soit le choix, il faut corréler; il y a là un travail d’humain. Ce qui est important, dans des grands déploiements, c’est à chaque niveau, d’être capable d’avoir un premier niveau de corrélation et, donc, de filtrage. Parce que si le nombre d’événements remontés est trop important – on parle de millions par jour dans certains cas –, c’est juste ingérable. Ou post mortem.

LeMagIT : Dans ce cas, avez-vous des éléments chiffrés indiquant le nombre de personnes nécessaires pour gérer un nombre N d’incidents quotidiens ?

Y.L.B : Il n’y a pas de règle. A nos clients, nous proposons d’utiliser notre solution pour assurer le premier niveau de corrélation, puis un second, avec l’humain, assisté par des résultats d’analyses actives. En tenant compte précisément de la corrélation temporelle des événements, bien sûr. Après, les variations sont fortes. Avec une bonne équipe, on peut gérer 20 ou 50 événements par jour voire… un seul, si c’est celui-là, cet événement critique, qui a du sens. 

En complément :

- Surveillance des attaques informatiques : l’Anssi « part d’une feuille blanche »