Une histoire pratique du pare-feu – Partie 2 : la valeur de la gestion

Jody Brazil, CEO de FireMon Check Point et les pare-feu à inspection dynamique ont remporté la première bataille face aux pare-feu proxy (Partie 1 : les débuts). Il serait facile d’affirmer que tout s’est joué sur la technologie d’inspection, mais ce serait passer à côté d’une innovation majeure de la solution Check Point : la gestion des politiques. Si les pare-feu à inspection dynamique l’ont emporté sur la concurrence des proxys au milieu des années 90, c’est en grande partie grâce à leur facilité de gestion. Une grande partie de cet article est consacrée à Check Point. Cela tient principalement au rôle dominant que Check Point a joué sur le marché des pare-feu à la fin des années 90 et au début des années 2000. Mais cela tient probablement aussi à mon exposition à Check Point durant ces années. Votre point de vue est le bienvenu et je me réjouis de lire vos commentaires. Le milieu des années 90 était une période d’évolution rapide des réseaux. Par exemple, l’ethernet était une option, mais pas toujours le protocole de réseau local utilisé (vous souvenez-vous du token ring ?). La connexion à Internet n’allait pas de soi, elle se discutait. L’accès commuté restait courant et AOL dominait le marché. Prétendre que les pare-feu étaient une technologie grand public reviendrait à mal comprendre la place d’Internet à l’époque. L’une des conséquences de cette évolution rapide des réseaux était une méconnaissance et un manque d’expérience considérables. Dans ce contexte, la facilité de gestion d’un pare-feu ne doit pas être négligée comme facteur clé ayant déterminé le vainqueur de ce marché. Aujourd’hui, dans le développement logiciel, nous parlons d’expérience utilisateur et d’ergonomie. Ces termes n’étaient pas à la mode à l’époque, mais les raisons pour lesquelles nous en parlons aujourd’hui comptaient tout autant alors. Les clients « préféraient » le produit. Ainsi, si la sécurité et les performances avaient leur importance, l’ergonomie de l’interface graphique du pare-feu Check Point ne doit pas être écartée. Pour citer un commercial de Gauntlet de l’époque : « Peu importait le prospect, dans chaque compte où j’allais, je devais me battre contre l’interface graphique de Check Point – et généralement perdre. » Check Point a lancé son pare-feu avec une gestion centralisée et une interface utilisateur très innovante. Parmi les capacités clés figuraient :

• Un éditeur de règles graphique
• Un référentiel d’objets centralisé partagé entre les politiques de pare-feu
• Une journalisation centralisée
• La gestion multi-domaines et OPSEC

L’éditeur de politiques de Check Point

Le concept d’une règle de pare-feu constituée d’un quintuplet – source, destination, protocole, port (protocole et port étant combinés en un seul objet appelé service) et action – existait bien avant l’éditeur de politiques de Check Point. Les premières listes de contrôle d’accès prenaient en charge ce concept dès les années 80. Check Point a toutefois changé le paradigme avec l’éditeur de règles graphique. Il n’était plus nécessaire de connaître la syntaxe CLI pour créer une règle. Une souris et quelques clics suffisaient. De plus, l’édition des règles s’est enrichie de fonctions utiles telles que le copier-coller, les commentaires définis par l’utilisateur et la possibilité d’insérer plusieurs objets par colonne. Ce dernier point, les objets multiples par colonne, était révolutionnaire. Les listes de contrôle d’accès antérieures ne prenaient en charge qu’une seule source, une seule destination et un seul service dans les colonnes respectives. La prise en charge de plusieurs objets rendait chaque règle plus puissante, et l’édition d’une politique consistait souvent à modifier une règle existante plutôt qu’à en créer de nouvelles. Cet éditeur de politiques reposait en grande partie sur une autre avancée : le référentiel d’objets centralisé.

Le référentiel d’objets centralisé de Check Point

Historiquement, les listes de contrôle d’accès étaient créées en référençant une adresse IP précise pour la source ou la destination. Cela fonctionnait, mais si l’adresse IP d’un système changeait, il fallait mettre à jour chaque règle. À l’image du code source réutilisable, Check Point a compris que créer un référentiel d’objets centralisé et utiliser ces objets dans les règles constituait une meilleure stratégie. Désormais, si un hôte changeait d’adresse IP, seul l’objet devait être mis à jour et la politique reflétait automatiquement cette modification, puisqu’elle utilisait une référence à l’objet stocké. Il était en outre possible de créer des groupes de ces objets (et des groupes de groupes) afin de réutiliser des ensembles d’objets courants dans toute la politique. Il s’agissait d’avancées considérables pour une gestion des politiques plus efficace.

Journalisation centralisée

Un problème extrêmement courant avec les pare-feu consiste à bloquer le mauvais trafic. C’est particulièrement vrai lorsqu’un pare-feu est placé entre deux réseaux qui n’étaient pas segmentés auparavant, ce qui était le cas de presque tous les nouveaux déploiements de pare-feu à la fin des années 90. La journalisation centralisée de tous les journaux de pare-feu, également facilement consultable, rendait le diagnostic des erreurs de politique très évident et comparativement simple. Un utilisateur pouvait signaler un problème, fournir une combinaison IP source / IP de destination, et un administrateur pouvait trouver le journal « drop » dans la visionneuse de journaux ainsi que la règle associée à l’origine du blocage (ou, à l’inverse, trouver un journal « accept » et indiquer à l’utilisateur qu’il se trompait). Les erreurs étaient, et restent, fréquentes dans l’administration des politiques de pare-feu : la facilité de dépannage constituait donc une valeur ajoutée essentielle pour toute plateforme de pare-feu.

Gestion multi-domaines et OPSEC

Au début des années 2000, Check Point a renforcé la puissance de la gestion en introduisant la gestion multi-domaines avec Provider-1 et les API d’intégration avec OPSEC. Ces deux initiatives constituaient un pari important sur la puissance de la gestion pour distinguer Check Point de ses concurrents sur le marché des pare-feu – et cela a fonctionné. Provider-1, comme son nom l’indique, visait la communauté des fournisseurs, les télécommunications et les fournisseurs de services managés. Si les fournisseurs ont été les premiers à adopter la technologie, les entreprises ont rapidement trouvé elles aussi des raisons de consommer le produit. Des capacités clés telles que le contrôle des autorisations, l’amélioration des performances de gestion et d’interface grâce au fractionnement des grandes politiques et bases de données d’objets, ainsi que les règles globales pouvant être appliquées et imposées à l’échelle mondiale, étaient autant de fonctionnalités recherchées par les grandes entreprises. Il s’agissait en grande partie de limitations de la plateforme de gestion standard. Certains pourraient soutenir que Check Point aurait dû corriger la plateforme de gestion plutôt que d’exiger des clients qu’ils paient un supplément important pour Provider-1, mais les clients en percevaient les bénéfices et étaient disposés à payer pour ces capacités de gestion avancées. OPSEC était un programme de partenariat et un ensemble d’API publiés par Check Point pour encourager l’intégration de produits tiers. Parmi les premiers succès figuraient des produits de reporting utilisant l’API Log Export (LEA), des produits de filtrage d’URL utilisant le protocole URL Filtering (UFP) et des produits de gestion, tels que FireMon, utilisant l’interface Check Point Management Interface (CPMI). Le programme et les intégrations ont rencontré un immense succès. Aujourd’hui, bien plus de 100 partenaires OPSEC proposent une forme d’intégration à la plateforme. Cet écosystème de produits de sécurité apporte aux clients une valeur ajoutée et une confiance accrue dans leur investissement. Aujourd’hui, les intégrations par API nous semblent aller de soi, mais en 2001, au lancement d’OPSEC, elles étaient loin d’être aussi répandues.

Cisco et la CLI, un acteur dominant

Le marché n’était pas entièrement dominé par Check Point et l’interface graphique. Tandis que Check Point s’imposait comme un leader du marché des pare-feu avec une interface graphique puissante et facile à utiliser, Cisco restait fidèle à ses origines avec une interface en ligne de commande (CLI) dans le Pix. Le Pix était un concurrent plus ancien sur le marché des pare-feu, remontant à 1994 et racheté par Cisco en 1995. La familiarité des administrateurs réseau avec Cisco et la CLI faisait du Pix le choix privilégié lorsque l’équipe réseau était responsable de la sécurité. Check Point allait grignoter cet avantage grâce à ses fonctions de sécurité et à son interface graphique, aidé par une lente évolution des structures organisationnelles des entreprises, la sécurité devenant une équipe distincte de l’équipe réseau. À mesure que cette évolution se produisait, la relation existante entre Cisco et l’équipe réseau a joué un rôle décroissant dans le choix du fournisseur de pare-feu. Les capacités de gestion améliorées ont contribué à asseoir la position de Check Point sur le marché et ont renforcé la valeur de la gestion pour les produits de sécurité. Mais, tout comme les performances avaient aidé Check Point à battre le proxy dans les années 90, elles allaient à nouveau devenir un critère de décision clé dans les années suivantes, et cette fois Check Point serait menacé. Partie 3 : les performances occupent le devant de la scène