Renaud DERAISON, (TNS): La licence GPL est avant tout une sorte de contrat entre le développeur et les utilisateurs

Par Xavier Poli, secuobs.com
Le 18/05/2004

---

Résumé : Instigateur du projet Opensource Nessus, le succès rapide de celui ci met fin à ses études d'ingénieur . Il fonde en 2000 une SSII appelée "Nessus Consulting" et "Tenable Network Security" en 2002. - Lire l'article



Instigateur du projet Opensource Nessus (scanner de vulnérabilité), le succès rapide de celui ci met fin prématurément à ses études d'ingénieur entamée plus tôt. Il fonde alors en l'an 2000 une société de services autour de Nessus appelée "Nessus Consulting". Les relations clientèles lui permettent de mieux cerner les besoins et les limites dans le domaine du recensement de vulnérabilités. Sa rencontre avec Ron Gula (l'auteur de du système de détection d'intrusion "Dragon") et leurs échanges leur permettent alors de réaliser qu'ils ont la même analyse du scan en entreprise et fondent la société Tenable Network Security fin 2002 aux Etats-Unis où il vit actuellement.

Comment est né le projet Nessus ?

Il est né de manière très simple : j'ai découvert Linux vers 1996 , et lorsque j'ai commencé à devenir plus familier avec ce système qui était tout nouveau pour moi, j'ai regretté l'absence d'un outil mis à jour faisant une sorte de "checklist" de la sécurité du point de vue réseau, et j'ai donc commencé à en écrire un de taille modeste nommé "Nessus".

Lorsque j'ai terminé la version initiale, je l'ai annoncée sur bugtraq (mi-1998) et à mon étonnement le plus total, j'ai reçu un retour tout à fait inattendu sur ce projet, et les utilisateurs m'ont encouragé à en continuer le développement, et c'est pourquoi six ans après je continue à faire évoluer ce dernier.

Comment justifier vous aujourd'hui le choix de la licence GPL ?

La licence GPL (et plus généralement toute licence dite "libre") est avant tout une sorte de contrat entre le développeur et les utilisateurs, typiquement,
elle garantit qu'un utilisateur qui fait un rapport de bug ou bien suggère une
excellente idée de fonctionnalité n'ait pas à payer pour utiliser le programme qui implémente la correction du bug ou la fonctionnalité elle-même. De fait, elle va donc favoriser un échange très riche entre développeurs et utilisateurs, ce qui permet à la fin de faire un produit qui colle davantage aux besoins du marché.

Dans le cas de Nessus, la GPL ne m'a pas amené énormément de développeurs (du moins en comparaison avec d'autres projets libres ayant une popularité similaire à Nessus), mais l'échange intensif avec les utilisateurs nous permet d'écrire un scanner beaucoup plus efficace que les alternatives propriétaires, car nous bénéficions d'un "laboratoire" bien plus grand que tous nos concurrents réunis, les utilisateurs de Nessus seront les premiers à rapporter qu'un test donné génère des faux positifs contre un serveur folklorique ou bien, pire encore, qu'il ne fonctionne pas.

Notre base d'utilisateurs étant extrêmement large par rapport aux autres scanners commerciaux, un test qui ne fonctionne pas correctement m'est rapporté extrêmement rapidement - parfois moins d'une heure après sa publication.

Est ce que certaines circonstances ont pu vous faire regretter ponctuellement ce choix par le passé ?

Mon grand regret ce sont les sociétés qui "contournent" la GPL, en vendant Nessus sous forme compilée sur une appliance et en changeant son nom pour faire croire qu'il s'agit du fruit de leur développement. Certains sont vraiment prêts à tout pour "devenir riche", même à perdre tout honneur et à mentir délibérément à leurs clients, c'est affligeant.

Combien de personnes travaille au développement de Nessus à l'exception des développeurs des modules NASL ?

Nous sommes deux à travailler sur le moteur : Michel Arboi et moi-même. Comme nous sommes une petite équipe, nous pouvons faire évoluer le moteur rapidement, sans avoir a passer par de longues discussions politiques sur le bien fondé de tel ou tel changement.

Estimez vous la communauté de développeurs attachée à Nessus suffisante aujourd'hui pour mener comme vous le souhaiteriez la suite de son développement ?

Je suis très content de l'état actuel des choses : les personnes qui m'envoient
des nouveaux tests de sécurité sont qualifiées et je ne passe pas trop de temps à revoir et améliorer les scripts, le moteur fonctionne très bien et son code est propre et facile à maintenir, et donc le projet avance à un bon rythme tout en me laissant le temps pour mes autres occupations professionnelles.

Quels sont les grandes fonctionnalités en développement pour la prochaine version de Nessus ?

La prochaine version de Nessus, qui sera Nessus 2.2, se focalisera principalement sur un meilleur suivi des audits - si un audit produit
un résultat négatif aujourd'hui, il n'est pas facile de savoir si c'est
parce que la machine distante est patchée, si le service testé est
d'une autre "marque" (IIS contre Apache), si c'est parce que le service
ne tourne pas du tout ou enfin si une erreur inattendue (ex: un problème
réseau) est survenu pendant le test.

Cette absence de suivi est un des reproches que je reçois le plus souvent - lorsque des utilisateurs scannent des milliers de machines pour un advisory particulier, ils veulent parfois "prouver" que leur réseau est sécurisé, et ce
n'est pas en montrant un rapport vide de failles qu'ils peuvent
le faire.

Combien de nouveaux modules nasl sont soumis et intégrés en moyenne chaque mois ?

Je ne garde pas trop ce genre de statistiques. Une quarantaine de nouveaux tests sont publiés chaque mois, ce qui n'inclue pas les "révisions" de certains
plugins (comme par exemple l'intégration des nouvelles signatures de systèmes d'exploitations et services que nous recevons tous les jours).

En ce qui concerne les plugins intégrés, environ 80% le sont. Parfois il m'arrive de recevoir des plugins mal écrits de la part de personnes qui débutent, et dans ce cas je ré-écris le plugin presque entièrement avant de le renvoyer à l'auteur en tachant de lui expliquer en une ligne ou deux ce qui n'allait pas.

Dans tous les cas, je tiens à préciser que les plugins sont testés avant d'etre inclus.

Quelles sont les raisons principales pour lesquelles un module peut être refusé ou non traité ?

La redondance serait une de premières raisons, mais aussi parfois le temps que prend un module pour s'exécuter : j'ai reçu un très beau script qui fait du "fuzzing" pour IPsec par exemple (et qui a d'ailleurs trouvé des bugs dans racoon, qui viennent d'etre fixés après six mois d'attente), mais il prend une demi-heure pour s'exécuter !

Sachant qu'il y a plus de 2,000 tests dans Nessus, tout module prenant plus que quelques secondes pour fonctionner est souvent rejeté, sauf s'il apporte une réelle valeur ajoutée au scanner.

Vous travaillez actuellement aux USA comme directeur R&D pour la société Tenable Network Security, serait il possible d'avoir plus de détails sur cette entreprise ?

Tenable est une société offrant des solutions de gestion de sécurité : scans de vulnérabilités, gestion des événements en provenance d'IDS et agrégation de logs.

Le tout est vendu sous la forme d'une solution simple et unifiée, qui permet une meilleure communication entre les équipes de sécurité et les équipes de l'IT.

Quels sont les produits que vous commercialisez ?

Nous commercialisons les produits suivant :

- NeWT est un Nessus fonctionnant sous Windows. Une version gratuite permet de scanner sa classe C locale, et une version commerciale est vendue pour scanner un nombre illimité de machines. Son avantage principal par rapport à Nessus est sa simplicité de déploiement et d'usage.

- NeVO est un scanner passif - il détecte des vulnérabilités lorsqu'il les voit passer.

- Thunder est un aggrégateur de logs - il peut recevoir des événements en provenance de syslog ou bien de ses propres agents, et centralise ceux-ci.

- Lightning est la console qui gère toute notre famille de produit. Lightning permet de gérer un grand nombre de scanners Nessus/NeWT/NeVO distribués aux quatre coins de la planète, de distribuer la mise à jour des plugins et d'attribuer des droits aux utilisateurs.

Pouvez vous nous décrire plus en détails les fonctionnalités de Lightning ?

Il est possible d'y envoyer des logs de la plupart des IDS du marché afin de corréler ceux-ci avec les vulnérabilités détectées afin de mieux prioriser le volume d'information à traiter.

Mais de manière plus importante, Lightning est avant tout une plateforme de communication entre l'IT et l'équipe de sécurité. Par exemple, un administrateur de serveurs DNS peut se connecter à la console, et il verra les failles, les événements d'IDS et les logs relatif à ses serveurs. Il lui sera par exemple possible de voir que ses serveurs ont tenté de scanner la planète la nuit dernière, ou bien de voir que ses requêtes DNS sont bloquées par le firewall. Il pourra aussi, au travers de Lightning, noter ce qu'il compte faire vis à vis des failles - patcher, désactiver le service, reconfigurer ce dernier, ou bien même accepter le risque.

Finalement, Lightning synthétise toutes ces informations pour générer un rapport de deux pages destiné au CIO, qui montre visuellement où sont les failles, ce qui fait l'équipe de sécurité et ce que font les administrateurs sur le terrain. L'idée étant que ce rapport permet à la fois de mieux mesurer le travail qui est réellement fait par les équipes de sécurité et de mieux comprendre ce qui s'est passé (ou pas) lorsqu'un ver réussi à rentrer dans l'entreprise...

Quels sont les avantages de votre solution de détection de vulnérabilité passive Nevo et ses principes de fonctionnement ?

Lorsqu'un scanner de vulnérabilité est lancé sur un réseau, il y a toujours des mauvaises surprises - le réseau est parfois plus lent, certains équipements peuvent planter, les imprimantes impriment des pages blanches pendant le scan, etc...

La raison c'est tout simplement qu'un scanner de vulnérabilité, par principe, va titiller chaque équipement sur un réseau, et que parfois ces équipements sont tellement mal faits et fragiles qu'ils plantent. Et même si dans 99% des cas il ne se passe rien de grave lors d'un scan, le 1% restant fait souvent peur aux équipes de sécurité qui limitent leurs scans à une fois par mois, trimestre ou même par an, ce qui diminue leur visibilité vis à vis de la sécurité du réseau.

Nous avons donc écrit NeVO : c'est un scanner entièrement passif, c'est à dire que comme un IDS il va sniffer le réseau et il va détecter les failles en fonction du traffic. Le principe est vraiment simple: sur un réseau, la plupart des services donnent beaucoup d'information vis à vis de leur numéro de version, tant du coté client que du coté serveur. En regardant ces numéros de version, il est possible de déduire les failles qui sont présentes sur le réseau.

NeVO permet donc de connaître un grand nombre de vulnérabilités "gratuitement", tant du coté serveur (qui est déjà audité par Nessus) que du coté client (qui n'est pas auditable autrement). Par exemple, NeVO va pouvoir repérer tous les utilisateurs qui utilisent une vieille version d'Outlook, ou bien même tous les PCs qui sont en train d'envoyer NetSky au reste de la planète.

Donc les avantages de NeVO sont les suivants :

- Facile à déployer sur un réseau, sans aucune mauvaise surprise
- Les vulnérabilités sont détectées en temps réel
- Les vulnérabilités du coté client sont détectées

En quoi consiste plus précisement la solution de corrélation d'évènements Thunder ?

Thunder est un module qui se connecte à Lightning est qui permet de normaliser et agréger des logs en provenance de centaines d'équipements - routeurs, serveurs Unix, etc.... L'interet principal de thunder est de simplifier l'analyse "post-mortem" d'une machine qui a été compromise.

Thunder est composé d'un serveur qui reçoit les logs, et d'agents (Windows, MacOS X, Linux) qui peuvent envoyer ces derniers de manière cryptée et authentifié au serveur. Il comporte un langage de script qui permet rapidement d'écrire de nouvelles signatures afin de pouvoir gérer des logs "maison".

Thunder s'intègre très bien à Lightning - par exemple, en voyant un événement IDS suspect dans Lightning il est possible en un seul clic de voir les évènements systèmes qui sont survenus peu avant et après ce dernier, et il est possible en un seul clic de voir les vulnérabilités de la machine incriminée.

Au niveau technique, comment faites vous pour gérer un tel flux d'évènements sans base de donnée ?

Nous utilisons des fichiers indexés. Les performances sont les mêmes, voire meilleures, qu'une base de données, et cela permet de faciliter le déploiement de nos solutions. En effet, nous n'avons pas encore rencontré d'équipe de sécurité au sein duquel se trouve un DBA.

Quel avis portez vous sur la sécurité des entreprises françaises face à la mentalité de leurs homologues américaines ?

Les entreprises françaises sont plus conservatrices lorsqu'il s'agit d'investir dans de la sécurité - notre cycle de vente en europe est trois à quatre fois plus long qu'aux Etats-Unis.

Suite à l'adoption de La Loi sur la Confiance en l'Economie Numérique (LCEN), de nombreux professionnels sont inquiets face à l'article 34 qui pourrait fortement remettre en cause l'avenir du full disclosure en France, l'utilisation de Nessus ou la diffusion de modules NASL pourraient être bientôt considérés ici comme illégaux, souhaitez vous exprimer une opinion à ce sujet ?

A mon avis, l'article 34 traduit très bien l'incompréhension totale des hommes politiques et rédacteurs de lois vis à vis du domaine sur lequel ils légifèrent. Ils ne comprennent rien à la sécurité informatique, alors de peur d'écrire des bêtises ils ont mis des termes extrêmement flous (qu'est ce qu'un "motif légitime" ?), et le premier juge à utiliser cet article les interprétera comme il le souhaitera, faisant ainsi jurisprudence.

Je tiens de plus à préciser que je ne vois aucun article mettant en cause les éditeurs dans cette loi - comme toujours, les éditeurs informatiques peuvent mettre des produits défectueux sur le marché, et comme toujours ce sont les utilisateurs qui en feront les frais, quitte à mettre ces derniers en prisons s'ils ont le malheur de communiquer sur le niveau d'(in)sécurité de certains produits...

Du point de vue de Nessus, cette loi ne va pas m'empêcher de dormir ni de continuer à faire évoluer le projet.


Renaud Deraison , je vous remercie de votre collaboration.