Eric Naegels, Lumension : « les listes blanches trouvent leurs limites sur la productivité »

LeMagIT : Lumension vient de lancer l’initiative Intelligent Whitelisting, pour la protection des postes de travail et la prévention de l’exécution de codes applicatifs non approuvés. Quelles sont les limites du whitelisting conventionnel auxquelles vous voulez pallier ?

Eric Naegels : Ce sont tout d’abord des aspects de productivité. Le concept et les technologies de liste blanche existent depuis 15 ans ; les produits depuis 10 ans. Avant de devenir Lumension, nous nous appelions SecureWave et nous commercialisions Application Control. Honnêtement, nous ne l’avons pas beaucoup vendu ou uniquement pour des configurations très spécifiques de machines qui ne bougent pas dans le temps, comme les distributeurs automatiques de billets de banque. Mais en tout cas pas pour des postes de travail, des portables ou des serveurs où les applications changent, soit parce que le portefeuille applicatif évolue, soit par qu’il faut appliquer des mises à jour. Avec ce genre de machines, la protection par liste blanche est quasiment impossible à exploiter : il faut une armée de personnes pour faire évoluer les listes tant bien que mal et en temps réel. En fait, en France, je ne connais qu’un seul client à l’avoir fait, pour les postes nomades de ses commerciaux itinérants. Et la problématique est la même pour tout éditeur de solutions de whitelisting : c’est celle de l’exploitabilité des solutions. C’est apparemment plus simple, sur le papier, que le blacklisting, mais c’est bien plus compliqué à mettre en œuvre dans la pratique et à gérer, dans le temps.

L’autre frein au whitelisting n’est pas technique : c’est juste que le marché du blacklisting reste fructueux pour les grands éditeurs. Même s’ils sont tous conscients d’arriver au bout de la technologie, car ils ont besoin d’être très réactifs, voire de travailler en anticipation. Et les bases de signatures sont devenues énormes ; les solutions utilisent donc de plus en plus de mémoire et de ressources CPU. Ils savent qu’il va falloir passer à autre chose mais eux-même se retiennent de peur de se couper l’herbe sous le pied. Et l’actualité - avec Stuxnet ou encore Conficker - montre qu’il y a des choses à faire.

LeMagIT : Justement, en quoi consiste votre approche ?

E.N. : Tout d’abord, elle consiste à prendre en compte les événements de la vie d’une machine et de son utilisateur. Il s’agit en premier lieu de faire en sorte que toute mise à jour de machine - application de Service Pack, de patch de sécurité, etc. - soit réalisable et totalement intégrée au système de whitelisting, avec prise en compte des signatures. Aujourd’hui, lorsqu’un utilisateur met à jour Internet Explorer ou iTunes de son côté, il est probable que son système cesse de fonctionner. Notre approche consiste à intégrer la notion de patch et de rémédiation dans la création et la maintenance de la liste blanche. 

Cela implique de ne pas laisser le produit se mettre à jour seul ; cela se fait via nos outils qui vérifient ascendances et descendances. Les mises à jour seront d’ailleurs déclenchées par notre système - de manière transparente pour les utilisateurs mais sous contrôle des administrateurs système. Un outil prévient ces derniers des vulnérabilités connues et suggère des solutions. Mais leur mise en œuvre relève de la décision des administrateurs.

Cette approche centralisée et contrôlée permet de régler 80 % des cas de figures où, par exemple, une simple DLL mise à jour pourrait bloquer un système. Dès lors, bien sûr, qu’on ne traite pas uniquement les produits Microsoft mais tous les éditeurs. Et nous avons d’ailleurs prévu un kit de développement pour supporter les applications métiers. C’est une solution qui est déjà déployée chez France 2, par exemple.

LeMagIT : Cela revient en quelque sorte à intégrer patch management et whitelisting ?

E.N. : Oui, avec un seul agent et une seule console. Mais il n’y a pas que ça. Notre initiative vise à créer une base de données mondiale de signatures d’applications légitimes. Cela consiste à aller voir les éditeurs et à les convaincre qu’il serait bon qu’ils participent à délivrer dès que possible la signature de tout nouveau binaire. Microsoft a déjà accepté de jouer le jeu. Notre approche est simple : il faut que tout le monde participe un peu si l’on veut, un jour, avoir du whitelisting qui fonctionne vraiment et de véritables chemins de confiance de l’éditeur à l’utilisateur.

En outre, pour les administrateurs, les rapports d’activités de l’agent de contrôle permettent d’identifier les usages des utilisateurs et de s’interroger : « de quoi s’agit-il ? Puis-je laisser mes utilisateurs s’en servir ? Lesquels ? » La présence d’une signature des logiciels ainsi relevés constituera un élément de confiance.

LeMagIT : Mais qu’il soit intelligent ou pas, le whitelisting nécessite tout de même un travail préalable conséquent...

E.N. : C'est vrai. Avant d’installer une solution de whitelisting, il est indispensable de faire du nettoyage. Dans cette perspective, une solution de gestion des actifs logiciels du parc peut permettre de réduire les coûts initiaux. Mais ce n’est pas indispensable. Ce qui l’est, c’est d’être sûr que l’on est en face d’un environnement sain. C’est d’ailleurs dans cette optique que nous avons noué un partenariat avec Norman pour intégrer à notre solution un dispositif contre les logiciels malveillants : à la première installation, ce module peut être activé en l’absence de solution tierce pré-existante. Sinon, nous utilisons les API des éditeurs d’antivirus

Après, on peut commencer par mettre en place la solution pour observer ce qui se passe, comme pour la DLP. C’est d’ailleurs ce qui a un peu rebuté certains clients dans un premier temps : le déploiement en mode audit, ou plutôt le résultat de ces audist. Certains ont déclenché de véritables fureurs en interne car ils sont extrêmement révélateurs des pratiques. Au point que le projet peut parfois être abandonné au regard de l’énormité de la tâche à accomplir pour assainir ces pratiques.