Quelle autre brique technologique symbolise plus la sécurité informatique que le pare-feu ? Sa définition parle d'elle-même. C'est un système qui filtre l'accès, telle une barrière, entre un réseau privé et internet. Ne laissant entrer que les utilisateurs et l'information autorisés, il évite les intrusions malveillantes dans le système d'information. Tout du moins le pense-t-on... Trop d'entreprises basent la défense de leur périmètre sur cette brique technologique. Le pare-feu a vieilli face aux nouvelles solutions.

Depuis maintenant plus d'un an, de nombreux gourous de la sécurité mettent en cause l'architecture classique du périmètre de sécurité de l'entreprise. Le pare-feu n'en serait plus la pierre angulaire. William R. Cheswick, grand expert du sujet, décrit ce dispositif comme une « coquille dure et croquante, enveloppant un noyau mou et fondant ». Laurent Charvériat, directeur général et CTO de Cyber Networks, pondère d'une analyse cette polémique autour de l'utilité de ce système : « Le pare-feu filtre les accès HTTP. Ce n'est pas son rôle de vérifier le contenu de l'information qui va transiter vers une application. » Ce faisant, c'est bien là que le bât blesse. « La sécurité applicative est la grande oubliée », s'étonne Laurent Charvériat, mettant le doigt sur la faille de cette « ligne Maginot » . L'explication tient à la nature du service d'un pare-feu. « Si j'autorise un flux vers telle base SQL via le port 80, il n'y a pas de demi-mesure : le flux transite », explique Siegfried Noël, consultant sécurité chez Telindus.

Que ce soit vers une base de données ou vers un serveur d'applications, ce schéma de fonctionnement laisse le champ libre aux tentatives d'intrusion. Dès lors, « soit vous apprenez à vos développeurs à produire du code parfaitement sécurisé, soit vous recourez au pare-feu applicatif », tranche Laurent Charvériat. Ce mécanisme ajoute une couche d'analyse des informations qui sont passées au serveur web. Son atout ? A la différence du pare-feu classique, dit aussi pare-feu réseau, il intervient au-delà de la couche 4 du modèle OSI. « Nous analysons les paramètres des requêtes pour empêcher les injections SQL, les " cross site scriptings " et autres attaques classiques » , explique Patrick Asty, directeur technique de Deny All, en évoquant son produit phare rWeb. Ce pare-feu applicatif fonctionne à partir de listes noires contre les attaques classiques. Un outil de validation fonctionnelle permet, par ailleurs, de prototyper l'utilisation qui peut être faite du serveur ou de l'application afin d'écarter tout comportement anormal.

Développement hérité d'un projet de la Société Générale datant de la fin des années 1990, la solution de Deny All donne un coup de vieux au pare-feu de type « stateful inspection » (inspection contextuelle des paquets). Selon Andrew Stevens, directeur marketing produits de Secure Computing, les « 4 à 5 % de parts sur le marché du pare-feu de Secure Computing ne sont pas significatives. Nous sommes les premiers sur le secteur du pare-feu applicatif, qui en sera la prochaine locomotive. » Check Point l'a bien compris, qui s'apprête à répliquer prochainement avec une solution combinant les deux technologies. Trop tard, peut-être, pour renverser la vapeur. Depuis 1998, déjà, NetASQ combine dans une « appliance » un pare-feu de type « stateful inspection » et un pare-feu applicatif, aboutissant à un système de prévention d'intrusions en temps réel. Cette association de pare-feu entre directement en concurrence avec les systèmes de détection d'intrusions (IDS).

Auparavant compléments du pare-feu, les IDS pourraient donc se marginaliser dans les architectures de sécurité. Les consultants en sécurité ne sont pas prompts à enterrer ces solutions. Mais ils en défendent timidement l'importance. « Les entreprises n'ont pas pris conscience qu'avec les IDS elles auraient une masse d'événements très importante à traiter. Cette négligence en a entraîné une autre, le manque de corrélation et d'analyse des événements », tente de justifier Aurore Seebaluck, responsable du pôle sécurité d'Euriware. Avant de souligner qu'ISS (leader du marché de l'IDS) « reste la référence dont tout le monde s'inspire » . Siegfried Noël stigmatise, pour sa part, la portée intrinsèque de l'IDS. « Encore faudrait-il que l'IDS sache ce qu'il doit contrôler ! Détecter des attaques sur IIS alors qu'on a des serveurs Apache n'est guère utile... », ironise-t-il. Il pointe du doigt le manque d'intelligence des IDS. Leur action sur les règles de filtrage des pare-feu ne suffit pas à les rendre plus pertinents. Certains parient sur l'amélioration des IDS par le recours à des outils de gestion des vulnérabilités. « Leur intégration dans les IDS a pour but d'éliminer ces " faux positifs ". En repérant les vulnérabilités des systèmes, nous garantissons que l'IDS surveille ce qui est nécessaire, à savoir les serveurs propices à une attaque extérieure », développe Philippe Courtot, CEO de Qualys.

Les éditeurs d'IDS insistent, eux, sur leur capacité à évoluer vers la protection. « Baser l'architecture de sécurité de son périmètre sur le couple pare-feu/IDS présente un très gros inconvénient : quand une intrusion passe la zone démilitarisée (DMZ), le ver est dans le fruit ; le pirate peut se jouer des serveurs internes au réseau », développe Philippe Destison, directeur de la division sécurité de Bull Services France et directeur opérationnel d'Evidian. Ainsi la détection d'intrusions se double-t-elle désormais de la prévention d'intrusions, ou IPS (Intrusion Prevention System). Du moins, sémantiquement : « L'IPS n'est que du marketing », s'amuse Aurore Seebaluck. Et de souligner que l'IDS a déjà bien à faire à séparer le grain de l'ivraie entre « faux positifs » et alertes véritables.

En réponse aux faiblesses de l'architecture classique à base de pare-feu et d'IDS en zone démilitarisée, Evidian pousse le concept de « distributed dedicated militarized zones » . Ce cloisonnement réseau par zones démilitarisées de production ­ protégées, dans le cas présent, par leur pare-feu applicatif Netwall ­ réduit les conséquences d'une intrusion. Ne sera affectée que la zone visée par l'intrusion. Principal frein de cette architecture : le coût. Ce que reconnaît volontiers Philippe Destison : « L'existant est incontournable, et il faut un fort avertissement pour conduire une entreprise à repenser son architecture. » La paire pare-feu/IDS a quelques beaux jours devant elle, tant que perdurera l'attentisme des entreprises en matière de sécurité.