Comprenez le risque lié aux politiques. Posez vos questions sur les politiques en langage courant. Demander une démo →

Published:

Une histoire pratique du pare-feu – Partie 4 : la nouvelle génération

by FireMon

Jody Brazil, CEO de FireMon À mesure que les performances du matériel et des logiciels se sont améliorées, l'écart de performance entre les pare-feu des différents fournisseurs s'est considérablement réduit. Si les exigences de performance n'ont pas diminué, la majorité des pare-feu parvenaient à les satisfaire, et ce critère est devenu beaucoup moins déterminant dans la décision. Le prochain champ de bataille se situerait dans les fonctionnalités allant au-delà du pare-feu traditionnel.

Le pare-feu de nouvelle génération

Pendant plus d'une décennie, le pare-feu « traditionnel » à inspection dynamique a constitué la norme du secteur. Si l'UTM a trouvé sa niche dans certains environnements, le pare-feu à inspection dynamique est resté la technologie dominante en entreprise jusqu'à ce que Palo Alto Networks définisse le « pare-feu de nouvelle génération », qui a connu une adoption significative sur le marché à partir de 2010. Plusieurs fonctionnalités clés caractérisaient le pare-feu de nouvelle génération :

  • Filtrage de paquets tenant compte des applications – capacité à définir des politiques et à contrôler le trafic en fonction de l'identité applicative de couche 7, indépendamment du port et du protocole
  • Contrôle d'accès basé sur l'utilisateur, indépendamment de l'adresse IP, de l'emplacement ou de l'appareil (grâce à l'intégration avec des plateformes d'authentification des utilisateurs telles qu'Active Directory)
  • Filtrage IPS intégré s'appuyant sur la même connaissance applicative de l'ensemble de la pile
  • Capacité à réaliser tout ce qui précède à des niveaux de performance comparables à ceux d'un pare-feu traditionnel à inspection dynamique, avec une analyse en une seule passe

Il convient de prendre un instant pour rappeler que Nir Zuk, le fondateur de Palo Alto, a également été ingénieur chez Check Point Technologies et ingénieur principal du premier pare-feu à inspection dynamique, ainsi que CTO de Netscreen, à l'origine de l'appliance pare-feu. Un parcours très impressionnant. Il a accordé une interview en 2010 détaillant cette histoire, qui mérite d'être lue.

Pénétration du marché par le pare-feu de nouvelle génération

Le pare-feu de nouvelle génération a dû affronter une concurrence acharnée de la part des fournisseurs en place. Les clients avaient investi massivement dans leur infrastructure existante, et la migration d'un fournisseur de pare-feu à un autre était (et reste) extrêmement complexe. Face à ce défi, Palo Alto Networks a eu l'intelligence de mettre en avant l'avantage de sa nouvelle technologie, capable de filtrer des applications comme Facebook à la périphérie du réseau afin de contrôler le comportement sortant des utilisateurs. En se concentrant sur cette nouvelle fonctionnalité, l'entreprise a pu conquérir des parts de marché et des clients sans attendre ni exiger un projet de remplacement complet du pare-feu. De ce fait, de nombreux clients ont commencé à déployer des pare-feu Palo Alto Networks en complément de leurs pare-feu existants. Après avoir acquis un client grâce à cette stratégie, Palo Alto Networks cherchait ensuite à étendre son empreinte dans l'environnement du client dans le cadre d'un projet standard de renouvellement des pare-feu. Une deuxième stratégie de marché fructueuse a consisté à promouvoir les capacités IPS intégrées du NGFW de Palo Alto Networks. Là encore, sans avoir à évincer un fournisseur de pare-feu en place, Palo Alto Networks pouvait vendre sa plateforme comme un IPS avancé. Après avoir établi une relation client, l'entreprise pouvait tenter de pénétrer davantage le compte avec l'ensemble des capacités de sa plateforme. Palo Alto Networks a profondément bouleversé le marché du pare-feu. Non seulement l'entreprise a pris des parts de marché aux fournisseurs en place, mais elle a changé la définition même du pare-feu. Finalement, la concurrence a dû rattraper son retard à mesure que le NGFW devenait la norme.

La plateforme

L'évolution du pare-feu ne s'est pas arrêtée. En tant qu'appliance réseau, le pare-feu occupe une position très intéressante. Il inspecte le trafic entre les segments du réseau, ce qui en fait un emplacement idéal pour ajouter des capacités de détection et de réponse. Les capacités IDS et IPS ont été introduites avec les UTM et les pare-feu de nouvelle génération, mais ce n'était que le début des fonctionnalités ajoutées. Réponse aux menaces, détection et blocage des logiciels malveillants, vérification des utilisateurs au niveau du réseau avec authentification multifacteur, listes noires dynamiques et bien plus encore. Le pare-feu est passé du statut de filtre de paquets à celui de plateforme de sécurité. Et les fournisseurs de pare-feu sont passés du statut de fournisseurs d'une solution unique à celui de fournisseurs de sécurité couvrant l'ensemble de la pile : protection des terminaux, capacités SIEM, détection des logiciels malveillants, profilage des menaces et bien plus encore.

L'avenir du pare-feu

L'évolution du pare-feu n'est pas achevée. Les technologies réseau changent rapidement et le pare-feu devra s'adapter. Le cloud, le SDN et les conteneurs menacent le rôle traditionnel du pare-feu. La segmentation réseau traditionnelle cède la place à des réseaux très plats – ce qui supprime beaucoup de complexité réseau, mais représente un défi de taille pour le pare-feu. Les fournisseurs de pare-feu actuels s'adapteront-ils à cet environnement réseau en mutation ? Les contrôles de sécurité natifs intégrés au cloud ou au SDN suffiront-ils ? De nouveaux fournisseurs émergeront-ils pour relever ces nouveaux défis et menacer les fournisseurs de pare-feu actuels ? L'avenir le dira. Ces deux dernières décennies ont été passionnantes pour observer l'évolution du pare-feu. Et je crois que nous sommes à l'aube d'une ère qui rendra les deux prochaines décennies plus passionnantes encore.

Une histoire pratique du pare-feu - Partie 4 | FireMon