Exploration de l'utilisation de la fonctionnalité NGFW dans un environnement de microsegmentation

Pendant près de deux décennies, pare-feux de nouvelle génération (NGFW) ont été un outil de sécurité essentiel. Mais alors que les réseaux actuels deviennent de plus en plus complexes, la protection périmétrique offerte par les NGFW permet de résoudre un problème de moins en moins pertinent.

Illumio étudie les possibilités d'implémenter les fonctionnalités NGFW dans un microsegmentation environnement, combinant les deux technologies pour offrir le type de sécurité requis par les réseaux complexes.

Dans première partie, j'ai passé en revue l'historique, la valeur et les défis des pare-feux de nouvelle génération (NGFW).

Dans ce deuxième article, je parlerai du « et si ? » scénario d'intégration d'un sous-ensemble de fonctionnalités NGFW dans une solution de microsegmentation. Je vais parler de différents cas d'utilisation et des fonctionnalités NGFW qui pourraient convenir à chacun d'entre eux.

Les NGFW fonctionnent pour le trafic nord-sud, mais ont du mal à gérer le trafic est-ouest

Le NGFW a été conçu autour de l'idée de protéger le périmètre d'un réseau, et en grande partie pour se protéger contre les menaces liées au trafic entrant. Dans le monde des réseaux, ce type de trafic est souvent appelé « nord-sud ». Cette terminologie provient de la pratique répandue qui consiste à dessiner un réseau avec la « bulle » Internet en haut, le trafic entrant dans le centre de données se déplaçant de haut en bas, ou du nord au sud. Le trafic à l'intérieur du centre de données est généralement dessiné comme se déplaçant latéralement, de gauche à droite ou de droite à gauche, et est donc souvent appelé « est-ouest ».

En utilisant cette terminologie, on peut dire qu'il existe un cas d'utilisation intéressant pour les NGFW utilisées dans un rôle nord-sud, comme je l'ai dit dans la première partie. Mais le cas d'utilisation de l'est-ouest est un peu moins certain. Cette deuxième déclaration vous a probablement fait mal au cou, alors permettez-moi d'être un peu plus précis à ce sujet.

Les pare-feux coûtent trois types d'argent : matériel, maintenance/support et configuration/surveillance. Malgré le coût élevé dans les trois catégories, le retour sur investissement des NGFW est assez clair pour le cas d'utilisation nord-sud. En ce qui concerne l'est-ouest, il s'avère que seul un sous-ensemble des fonctionnalités complètes du NGFW est pertinent, mais les fournisseurs ne vous accordent pas de réduction si vous n'utilisez pas l'ensemble complet des fonctionnalités. Il est souvent difficile de justifier l'achat d'un appareil NGFW complet et de n'utiliser que la moitié des fonctionnalités, d'autant plus dans les cas où l'ensemble des fonctionnalités du NGFW n'est pas obligatoire par la loi ou la réglementation.

NGFW pour le trafic sud-nord

Ce sont deux des bons cas d'utilisation d'un NGFW, mais il y en a en fait un troisième que les gens considèrent rarement, sauf en passant : le cas d'utilisation sud-nord, ou en anglais, contrôlant le trafic sortant depuis l'intérieur du réseau. Les vendeurs de la NGFW en parlent, mais peu. Et la plupart des entreprises, bien que conscientes de la menace que représentent les connexions sortantes illimitées, font remarquablement peu pour y faire face. En travaillant avec de nombreux clients au fil des ans, j'ai découvert que la plupart des organisations n'avaient même pas mis en place de processus permettant aux propriétaires de leurs applications internes de demander des contrôles sortants à la frontière du réseau.

Mon travail est essentiellement de la R&D, en me concentrant principalement sur la partie « R ». Dans cette optique, faisons une expérience de réflexion. Imaginons un instant que le problème nord-sud est résolu. Ce problème n'est pas résolu dans le sens où il n'existe pas de solution parfaite à 100 %, mais dans le sens où la plupart des organisations ne considèrent plus cette voie comme la principale voie d'attaque contre leurs réseaux. Réfléchissons plutôt à la manière dont les réseaux pourraient être sécurisés si vous pouviez implémenter certaines fonctionnalités NGFW dans votre solution de microsegmentation et améliorer vos contrôles des NGFW est-ouest et sud-nord, sans avoir à acheter d'équipement supplémentaire ou à gérer vos propres processus organisationnels internes qui vous empêchent de tirer parti des fonctionnalités NGFW sortantes.

Les cas d'utilisation sud-nord et est-ouest sont différents, mais ils se chevauchent considérablement. De plus, de nombreuses caractéristiques nord-sud ne sont tout simplement pas pertinentes pour l'une ou l'autre de ces caractéristiques. Commençons par le cas d'utilisation est-ouest.

Comme je l'ai dit plus tôt, il existe certainement un cas d'utilisation pour un sous-ensemble limité de contrôles est-ouest des NGFW. Le retour sur investissement d'une appliance complète (ou d'une appliance virtuelle) peut être discutable, compte tenu de son coût, mais le besoin n'en est pas moins réel. Si votre réseau contient des informations personnelles, HIPPA ou PCI données, vous êtes presque certain d'être soumis aux lois et réglementations concernant la protection de ces données. Dans de nombreux cas, cela inclut l'obligation explicite de mettre en œuvre des services NGFW traditionnels tels que DLP (Data Loss Prevention) et IDS/IPS (Intrusion Detection/Prevention Service). Même s'il n'y a pas de mandat, cela reste une bonne pratique. L'ID d'application, en d'autres termes, la capacité de bloquer ou d'autoriser le trafic en fonction du type de trafic réel, par opposition au port et au protocole, est également un outil puissant et souhaitable pour empêcher les attaques et l'exfiltration de données.

Pour le cas d'utilisation sud-nord, quelques fonctionnalités supplémentaires peuvent être utiles. La DLP est probablement toujours nécessaire, et l'ID d'application est tout aussi utile dans ce cas d'utilisation, mais j'ajouterais à cela le filtrage des URL et la possibilité de contrôler le trafic en fonction de la réputation et de la géographie de l'IP de destination. Bien sûr, votre NGFW frontalier peut déjà le faire, mais comme je l'ai souligné plus tôt, le propriétaire de l'application n'a souvent aucun moyen de tirer parti de ces fonctionnalités si les appareils en bordure ne sont pas sous son contrôle. Et ils se trouvent rarement dans un environnement de centre de données de grande taille.

La plupart des autres services de la NGFW ont une valeur limitée pour l'est-ouest ou le sud-nord. Les attaques DDoS et la QoS n'ont guère de sens au sein d'un réseau. De même, les logiciels antivirus modernes exécutés dans le système d'exploitation sont probablement plus efficaces qu'une solution basée sur le réseau, de sorte qu'un antivirus basé sur le réseau n'est probablement pas à l'ordre du jour.

Les performances des fonctionnalités NGFW sur les terminaux

Il est temps de parler des implications en termes de performances des fonctionnalités NGFW exécutées sur points finaux. Si vous vous souvenez bien, la première partie mentionnait que les appareils NGFW étaient presque des systèmes de la classe des superordinateurs dotés de nombreux matériels spécialisés pour obtenir des performances respectables. Il s'ensuit évidemment qu'une baisse de performance substantielle serait imposée aux serveurs individuels lors de la mise en œuvre de la même fonctionnalité. Heureusement, cela semble être l'un de ces moments où l'intuition passe par la fenêtre. Voyons pourquoi.

L'IDS/IPS est un excellent point de départ. De tous les services NGFW, l'IDS/IPS est considéré comme l'un des « plus lourds », ce qui signifie qu'il consomme un nombre disproportionné de ressources. C'est l'une des raisons de la grande quantité de silicium personnalisé contenue dans une appliance NGFW. Si je protège un centre de données de taille moyenne de 1 000 charges de travail à l'aide d'une solution IDS/IPS, je dois probablement prendre en charge les signatures IDS/IPS pour au moins une douzaine de systèmes d'exploitation différents (Windows 2008, 2012, 2016, 2019, au moins une demi-douzaine de variantes et de versions de CentOS, RedHat et Ubuntu (et peut-être Solaris ou AIX, si je travaille dans le secteur de la santé ou dans le secteur bancaire). Chacun de ces 1 000 serveurs exécute au moins un service que je voudrais surveiller, peut-être jusqu'à trois ou quatre services différents chacun, qui présentent tous des vulnérabilités potentielles. Et avec une douzaine de systèmes d'exploitation, j'utilise peut-être une douzaine de versions différentes de chacun de ces trois ou quatre services, chacun présentant des vulnérabilités différentes.

Bref, je recherche entre 10 000 et 100 000 signatures de vulnérabilité pour ces milliers de machines. Et je recherche des signes de ces signes dans chaque paquet qui passe par mon périphérique réseau NGFW, sur tous les ports possibles qu'ils peuvent exploiter. Il ne s'agit clairement pas d'une charge que nous voulons imposer à tous les serveurs du centre de données.

Dans la pratique, nous n'en avons pas besoin. Il n'y a aucune raison de rechercher des vulnérabilités Windows sur un hôte Linux. Il n'est pas nécessaire de rechercher les vulnérabilités d'Apache2 sur une machine utilisant NGINX. Il n'est pas nécessaire de rechercher les vulnérabilités d'Application X version 1.0, 1.1, 1.2, 1.3, 2.0, 2.1 sur un système exécutant Application X version 2.2.

Au lieu de rechercher 10 000 à 100 000 vulnérabilités dans chaque paquet, nous en recherchons peut-être quatre. Pas 4 000. Quatre. Et quatre est un problème qui peut être résolu.

Comment ? Parce que le fait d'avoir un agent sur chaque serveur, nous avons un accès complet pour comprendre le système d'exploitation, les correctifs qui ont été appliqués et ceux qui n'ont pas été appliqués, les logiciels (et les versions de ces logiciels) installés et en cours d'exécution, et plus particulièrement les ports sur lesquels ils communiquent. Nous recherchons les vulnérabilités spécifiques aux versions du système d'exploitation et des logiciels détectées, en particulier sur les ports auxquels les processus concernés sont liés. Nous réduisons l'espace de recherche d'environ quatre ordres de grandeur. Et quatre ordres de grandeur, c'est un chiffre incroyablement élevé en informatique. C'est la différence entre difficile et facile.

Des stratégies similaires pourraient être appliquées à des services tels que le DLP et le filtrage d'URL. Il n'est pas nécessaire de filtrer chaque paquet de chaque serveur pour détecter le contenu DLP restreint, ni de conserver d'énormes bases de données contenant des URL ou des informations IP pour les adresses publiques de chaque serveur. Dans le cas de la DLP, vous recherchez uniquement du contenu spécifique sur un ensemble très spécifique de serveurs en fonction des étiquettes de charge de travail, de la même manière que la politique de segmentation est appliquée. Pour le filtrage des URL, la vaste base de données de caractéristiques IP peut être conservée dans le système central de gestion des politiques, récupérée via une connexion LAN à faible latence si nécessaire et mise en cache localement pour les recherches ultérieures. La plupart des serveurs communiquent encore et encore avec le même ensemble relativement restreint de serveurs.

Fonctionnalités NGFW pour une solution de microsegmentation

Lorsque vous ajoutez des fonctionnalités NGFW à un microsegmentation solution, l'un des avantages dont vous bénéficiez le plus est que, tout comme la politique de pare-feu, les fonctionnalités NGFW sont appliquées chirurgicalement, précisément là où vous en avez besoin, plutôt qu'à des VLAN entiers ou à des sous-réseaux en tant que groupe. Une politique basée sur des étiquettes permet au propriétaire de l'application d'appliquer des services très spécifiques de manière chirurgicale, précisément là où cela est nécessaire, au lieu de peindre le centre de données avec un pinceau large. Les fonctionnalités spécifiques du NGFW ne peuvent être activées que pour les serveurs nécessaires et ne peuvent effectuer que l'inspection requise avec précision. Cela permet de réduire les frais généraux au strict minimum requis pour répondre à vos besoins de sécurité spécifiques et de trouver un équilibre entre sécurité, performances et coûts.

N'oubliez pas que l'objectif ici n'est pas de remplacer vos appareils Border NGFW. Il s'agit plutôt de combler de manière sélective les lacunes lorsque les solutions NGFW existantes ne présentent aucun intérêt architectural ou financier grâce à un puissant sous-ensemble de fonctionnalités NGFW exécutées sur les serveurs eux-mêmes. Cette approche permet aux propriétaires d'applications de « s'approprier » leur sécurité sortante là où cela ne serait pas possible autrement, et de proposer ces fonctionnalités dans des situations qui seraient autrement prohibitives en termes de coûts avec les solutions traditionnelles.

Perspectives d'avenir

Pour y remédier, regardons encore plus loin dans l'avenir.

Le protocole TLS 1.3 a été ratifié en 2018 et est en train de devenir lentement la prochaine norme pour les services Web et autres services chiffrés. Votre première réaction à cela pourrait être : « Ce n'est pas mon problème » ou peut-être « Et alors ? » Je dirais que c'est en fait extrêmement pertinent. Un NGFW ne peut pas fournir la plupart des services disponibles sans une inspection approfondie des paquets (DPI). Et pour que le DPI soit significatif, les données doivent être en texte clair et non cryptées.

Lorsque les NGFW sont arrivés sur le marché pour la première fois, seule une infime fraction du trafic Web était cryptée. Au fil du temps, de plus en plus de trafic a été transféré vers HTTPS, ou trafic crypté. Aujourd'hui, près de 100 % de tout le trafic Web est crypté et ne peut donc pas être analysé pour détecter les logiciels malveillants, les virus, l'exfiltration de données ou tout autre serveur NGFW. La solution qui a été développée pour cela s'appelle TLS MiTM (man-in-the-middle).

La configuration de TLS MiTM est un peu fastidieuse, bien que son concept soit simple. La solution comporte un certain nombre d'éléments mobiles. Tout d'abord, l'organisation crée un certificat TLS interne. La clé publique est transmise à tous les systèmes (ordinateurs portables, ordinateurs de bureau, serveurs, etc.) de l'organisation, et chaque système d'exploitation est configuré pour faire confiance à ce certificat et l'utiliser pour crypter toutes les communications sortantes, quelle que soit leur destination. La clé privée est ensuite distribuée aux appareils NGFW de votre périmètre, qui sont configurés en tant que proxys Web transparents.

Lorsqu'un utilisateur (ou un serveur ou tout autre appareil) établit une connexion sortante vers un site Web externe, par exemple gmail.com, au lieu d'utiliser le certificat Google TLS, il chiffre le trafic avec le certificat interne de l'organisation. Lorsque le NGFW de périmètre détecte ce trafic sortant, il est capable de le déchiffrer et d'analyser complètement le contenu du trafic grâce à une copie de la clé privée. Le NGFW met fin à la connexion interne et établit une nouvelle connexion TLS à gmail.com à l'aide du certificat Google, et transmet par proxy le contenu des deux connexions (la connexion interne depuis l'intérieur de l'organisation vers la connexion externe à Gmail) et est ainsi en mesure de visualiser et d'analyser tout le trafic, même s'il est crypté.

Bien que fastidieuse et gourmande en ressources processeur, cette méthode fonctionne assez bien pour la plupart des services depuis une dizaine d'années en utilisant SSL, puis TLS 1.0, 1.1 et 1.2.

Jusqu'ici, tout va bien. Mais TLS 1.3 change la donne. Tout d'abord, TLS 1.3 impose le Perfect Forward Secrecy, sous la forme d'échanges de clés DH par connexion. De ce fait, un périphérique passif n'a aucun moyen de déchiffrer la charge utile, même s'il a accès à la clé privée en cours d'utilisation. Avec TLS 1.3, il est obligatoire d'insérer un appareil dans le flux et de transmettre le trafic par proxy. Deuxièmement, TLS 1.3 rend obsolètes les chiffrements les moins sécurisés, empêchant ainsi un périphérique proxy de rétrograder une connexion proxy vers TLS 1.2, qui est une stratégie courante souvent utilisée pour économiser des ressources de calcul dans le NGFW (car les chiffrements à faible sécurité nécessitent généralement moins de calculs).

Si l'histoire de la cryptographie nous a appris quelque chose, c'est que les anciennes normes fiables ont tendance à se révéler vulnérables au fil du temps avec une certitude de presque 100 %. La pratique actuelle qui consiste à rétrograder TLS 1.3 à TLS 1.2 pour permettre un déchiffrement passif et/ou une rétrogradation pour économiser des ressources est chronométrée, il ne reste plus qu'à attendre que TLS 1.2 soit obsolète. Le jour venu, un grand nombre de dispositifs d'inspection passifs deviendront des presse-papiers coûteux, tandis que de nombreuses solutions en ligne seront rapidement dépassées car elles seront obligées d'utiliser une cryptographie plus coûteuse en termes de calcul.

Un petit secret du monde de la NGFW est que, du moins au moment de la rédaction de cet article, votre trafic WebSocket n'est probablement pas inspecté pour détecter des menaces d'aucune sorte. Pourquoi ? Parce qu'un NGFW classique ne peut pas déchiffrer le trafic en temps réel. Le trafic WebSocket doit être visualisé dans votre navigateur (à l'aide des outils de développement) ou capturé et déchiffré après coup à l'aide de quelque chose comme Wireshark (en supposant que vous ayez les clés privées) afin d'inspecter la charge utile. Les WebSockets sont de plus en plus courants dans les applications Web, car cette technologie constitue une excellente solution permettant aux applications JavaScript de déplacer des données entre votre navigateur et un serveur Web. Tout peut littéralement être déplacé via une connexion WebSocket, et c'est complètement opaque pour votre NGFW.

Enfin, n'oublions pas d'autres nouvelles technologies omniprésentes, telles que l'utilisation de QUIC pour le trafic Web. Bien que QUIC soit un nouvel outil puissant permettant d'acheminer le trafic vers votre navigateur plus rapidement et plus efficacement, il n'utilise pas le cryptage TLS standard. Cela signifie que votre NGFW en ligne doit soit bloquer tout le trafic QUIC (forçant une rétrogradation vers le protocole TLS), soit autoriser le trafic à passer sans inspection. La première solution réduit la qualité de l'expérience utilisateur et la seconde expose l'organisation à des risques. Aucun des deux n'est idéal.

La gestion de certaines tâches NGFW au niveau de la charge de travail contribue à prolonger la durée de vie de l'investissement dans les appareils NGFW existants. Il permet de décharger un certain pourcentage de processus coûteux en calculs en les gérant par charge de travail. Cela permet au client de décharger une partie de la charge utile d'inspection de ses périphériques réseau, retardant ainsi une mise à niveau du pare-feu qui serait autrement nécessaire, tout en apportant les avantages de Zero Trust à des parties de son réseau qui pourraient autrement ne pas avoir de sens technique ou financier.