L'histoire et les défis des pare-feux de nouvelle génération

Il y a environ seize ans, en 2007, Palo Alto Networks a lancé son premier produit, modifiant à jamais la sécurité du réseau. Le terme « Pare-feu de nouvelle génération », ou NGFW, n'avait pas encore été inventé. Cela se produirait lorsque Gartner a introduit le terme en 2009. À l'époque, les produits de Palo Alto relevaient de l'ancien terme « Unified Thread Management », ou UTM. Bien que Palo Alto n'ait pas inventé l'UTM ni le NGFW, ils sont depuis devenus le produit phare dans ce domaine, par rapport auquel tous les concurrents sont comparés. Pour les besoins de cet article, nous allons simplement utiliser le surnom NGFW pour plus de simplicité.

Bien que ce que nous appelons aujourd'hui « le cloud » existait certainement en 2007, les centres de données étaient encore en grande partie construits de manière traditionnelle : une enveloppe de sécurité robuste autour d'un centre de données et de calcul souple et gluant. Seules les organisations les plus audacieuses transféraient leurs actifs vers AWS (Amazon Web Services) et d'autres nouveaux services cloud. Le centre de données avait toujours une limite définie et connue. Les limites entre les actifs situés à l'intérieur du centre de données et ceux situés à l'extérieur étaient clairement définies. ‍

NGFW : parfait pour protéger le périmètre du centre de données

Le NGFW, avec ses nombreuses fonctionnalités de sécurité puissantes, convenait parfaitement à ce modèle. Les NGFW sont rapidement devenues les gardiens des centres de données, contrôlant soigneusement ce qui entrait (et dans une bien moindre mesure, ce qui sortait) d'un réseau donné. De puissants processeurs personnalisés analysaient et transféraient les paquets rapidement en cours de route, et les responsables de la sécurité dormaient un peu mieux la nuit, sachant que leurs actifs étaient protégés par une suite de nouveaux outils.

NGFW des fournisseurs tels que Réseaux Palo Alto, Check Point et Fortinet se sont désormais fixé un nouvel objectif : dominer le centre de données, surveiller et contrôler le trafic entre les applications, car segmentation du réseau est devenue à la mode en tant que « nouveauté à la mode ».

Ici, cependant, ils étaient confrontés à un défi bien plus important. Les NGFW étaient un choix évident pour protéger le périmètre du centre de données. Le coût prohibitif du matériel, des licences et du support était justifié par les avantages évidents, et le prix a été maîtrisé par le fait que les connexions Internet aux centres de données étaient relativement lentes par rapport à la connectivité interne, et le prix augmentait avec la bande passante. À l'intérieur, cependant, on ne trouvait pas un rapport coûts/avantages aussi clair. Un pourcentage significatif de Caractéristiques du NGFW, prenez l'atténuation des attaques DDoS ou la mise en forme du trafic par exemple, n'avaient aucune valeur intrinsèque. Mais tu les as payés, peu importe.

Comme si le coût exorbitant d'un débit de 10 Go n'était pas suffisamment dissuasif pour un usage interne, chaque coût a été doublé pour des raisons de redondance. Il était extrêmement difficile de justifier cinq fois les dépenses d'un pare-feu traditionnel pour un ensemble de fonctionnalités excessives et souvent non pertinentes pour la tâche à accomplir.

Cela dit, les réglementations industrielles et gouvernementales exigent certains contrôles internes, du moins pour certaines catégories d'applications. HIPPA et PCI me viennent à l'esprit comme des exemples remarquables. Les clients ont donc opté pour des solutions hybrides, avec des dispositifs NGFW protégeant la frontière et quelques applications critiques et spécifiques, les technologies traditionnelles non NGFW prenant le relais de la protection interne. Ce mariage malheureux entre l'ancien et le nouveau a fonctionné pendant un certain temps. Jusqu'à ce que le cloud public soit accepté par le grand public.

Gérer la complexité des NGFW dans le cloud

Le cloud public a bouleversé le monde de la sécurité. Mais pas pour tout le monde, et pas toujours de façon évidente.

N'oubliez pas que les NGFW effectuent une quantité impressionnante de traitements sur chaque paquet qui passe par leur châssis. L'architecture Intel, aussi omniprésente soit-elle, n'est pas un bon choix compte tenu de l'énorme quantité de travail de bas niveau à effectuer au sein d'un NGFW. Palo Alto a choisi les processeurs réseau Cavium pour effectuer toutes ces inspections et manipulations de paquets de bas niveau. Fortinet a conçu ses propres processeurs clients internes pour effectuer le travail.

Le NGFW d'aujourd'hui, selon les normes d'il y a seulement dix ans, est un superordinateur de la classe des agences gouvernementales, ce qui représente certainement une partie des coûts. Les fournisseurs de NGFW ont rapidement réagi à la migration vers le cloud en proposant des versions virtuelles de leurs produits, mais les performances étaient globalement décevantes en raison des limites de l'architecture Intel.

Cela a entraîné des changements majeurs dans la manière dont la sécurité était gérée à la frontière des réseaux cloud. Souvent, des douzaines de pare-feux virtuels étaient équilibrés en charge. Les réseaux ont été repensés pour disposer d'un plus grand nombre de points de peering Internet qu'à l'époque traditionnelle, ce qui a permis de réduire les exigences en matière de performances par pare-feu. Et les fournisseurs de pare-feu ont commencé à vendre leurs implémentations de machines virtuelles (machines virtuelles) en packs de six et de dix, car un ou deux pare-feux ne pouvaient plus faire l'affaire.

Si cela semble complexe à créer et à gérer, dommage pour les entreprises classiques qui n'ont transféré qu'une partie de leurs actifs vers le cloud. Comme les deux IaaS (Infrastructure en tant que service) et PaaS (Plate-forme en tant que service) proliférant, les limites du réseau ont commencé à devenir de plus en plus indistinctes. Alors que la définition informatique du terme « cloud » découlait de l'idée qu'un grand nombre d'ordinateurs (comme la vapeur d'eau) étaient considérés comme un seul ordinateur vu de loin, il est devenu plus approprié d'utiliser une définition différente : « Quelque chose qui masque ou qui tache ».

Lorsque les centres de données ont commencé à héberger une sélection aléatoire d'applications et de parties d'applications dans le cloud, tandis que d'autres applications (et parties d'applications) restaient sur site, il est devenu extrêmement difficile de les protéger et d'appliquer une politique de sécurité. Cela s'explique en grande partie par le fait qu'il est devenu presque impossible de définir les limites, là où la sécurité est généralement appliquée. Et même dans les cas où les limites étaient claires, le volume considérable de matériel, de logiciels et de configuration de sécurité devenait écrasant.

En conséquence, la sécurité a fait un grand pas en arrière.

Tourné vers l'avenir : les fonctionnalités du NGFW dans un environnement de microsegmentation

C'est ainsi qu'a commencé la région de ce qui était connu au début sous le nom de microsegmentation, et ce que l'on appelle aujourd'hui plus souvent la segmentation Zero Trust (ZTS).

Le concept de microsegmentation est simple : appliquer des politiques (c'est-à-dire des pare-feux) sur chaque serveur, contrôler à la fois le trafic entrant et sortant vers tous les autres serveurs. Fondamentalement, la microsegmentation n'est qu'une extension de l'idée de segmentation du réseau poussée à son paroxysme (un pare-feu par serveur). La microsegmentation a fourni aux équipes de sécurité un nouvel outil puissant pour faire face aux « limites floues » autour et au sein de nos centres de données en abordant la sécurité serveur par serveur (ou du moins application par application).

Historiquement, la microsegmentation a permis de traiter les ports et les protocoles sans entrer dans le domaine de l'inspection approfondie nécessaire aux caractéristiques des NGFW.

Au sein du Bureau du CTO, mon travail consiste à jouer « et si ? » et essayez d'envisager les problèmes futurs potentiels et leurs solutions possibles. Ainsi, les recherches actuelles d'Illumio portent notamment sur les possibilités de mise en œuvre des fonctionnalités NGFW dans un environnement de microsegmentation.

Lisez mon blog la semaine prochaine pour en savoir plus sur les recherches d'Illumio et sur ces futurs développements potentiels en matière de microsegmentation.