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

Depuis près de vingt ans, les pare-feu de nouvelle génération (NGFW) constituent un outil de sécurité essentiel. Mais comme les réseaux d'aujourd'hui deviennent de plus en plus complexes, la protection du périmètre offerte par les NGFW résout un problème qui devient de moins en moins pertinent.

Illumio étudie les possibilités de mettre en œuvre les fonctions du NGFW dans un environnement de microsegmentation, en combinant les deux technologies pour offrir le type de sécurité requis par les réseaux complexes.

Dans la première partie, j'ai présenté l'histoire, la valeur et les défis des pare-feu de nouvelle génération (NGFW).

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

Les NGFWs fonctionnent pour le trafic nord-sud - mais peinent pour le trafic est-ouest

Le NGFW a été conçu autour de l'idée de la protection du périmètre d'un réseau, et en grande partie autour de la protection contre les menaces dans le trafic entrant. Dans le monde des réseaux, ce type de trafic est souvent appelé "nord-sud". Cette terminologie découle de la pratique répandue consistant à dessiner un réseau avec la "bulle" Internet au sommet, 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 qualifié d'"est-ouest".

En utilisant cette terminologie, on peut dire qu'il existe un cas d'utilisation puissant pour les NGFW utilisés dans un rôle nord-sud, comme je l'ai mentionné dans la première partie. En revanche, l'utilisation de l'axe est-ouest est un peu plus incertaine. Cette deuxième affirmation a probablement fait dresser quelques cheveux sur votre nuque, aussi permettez-moi d'être un peu plus précis à ce sujet.

Les pare-feu coûtent trois types d'argent : le matériel, la maintenance/l'assistance et la configuration/la 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'axe 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 rabais si vous n'utilisez pas l'ensemble des fonctionnalités. Il est souvent difficile de justifier l'achat d'une appliance NGFW complète et de n'utiliser que la moitié des fonctionnalités, d'autant plus dans les cas où l'ensemble des fonctionnalités NGFW n'est pas imposé par la loi ou la réglementation.

NGFWs pour le trafic sud-nord

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

Mon travail consiste essentiellement en R&D, avec un accent particulier sur la partie "R". Dans cette optique, faisons une expérience de pensée. Considérons un instant que le problème nord-sud est résolu. Le problème n'est pas résolu dans le sens où il n'existe pas de solution parfaite à 100%, mais il l'est dans le sens où la plupart des organisations ne considèrent plus ce chemin comme la principale voie d'attaque de leurs réseaux. Réfléchissons plutôt à la manière dont les réseaux pourraient être rendus plus sûrs si vous pouviez mettre en œuvre des fonctions NGFW sélectionnées dans votre solution de microsegmentation et améliorer vos contrôles NGFW est-ouest et sud-nord, sans avoir à acheter plus d'équipement ou à lutter contre vos propres processus organisationnels internes qui vous empêchent de tirer parti des fonctions NGFW sortantes.

Les cas d'utilisation sud-nord et est-ouest sont différents, mais ils se recoupent largement. En outre, de nombreuses caractéristiques nord-sud ne sont tout simplement pas pertinentes pour l'un ou l'autre de ces objectifs. Commençons par le cas d'utilisation est-ouest.

Comme je l'ai dit précédemment, il existe certainement un cas d'utilisation pour un sous-ensemble limité de contrôles NGFW est-ouest. Le retour sur investissement d'une appliance complète (ou d'une appliance virtuelle) peut être discutable, compte tenu du coût, mais le besoin est néanmoins réel. Si votre réseau contient des données PII, HIPPA ou PCI, vous êtes presque certain d'être soumis aux lois et réglementations relatives à la protection de ces données. Dans de nombreux cas, il s'agit d'une exigence explicite de mise en œuvre de 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'identification des applications, en d'autres termes la capacité de bloquer ou d'autoriser le trafic en fonction du type réel de trafic, par opposition au port et au protocole, est également un outil puissant et souhaitable pour prévenir les attaques et l'exfiltration de données.

Pour le cas d'utilisation sud-nord, quelques fonctionnalités supplémentaires pourraient s'avérer utiles. Le DLP est probablement encore nécessaire, et l'Application ID est également utile pour 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 de l'IP de destination et de la géographie. Bien sûr, votre NGFW frontalier peut déjà le faire, mais comme je l'ai souligné précédemment, il n'y a souvent aucun moyen pour le propriétaire d'une application de tirer parti de ces fonctionnalités si les dispositifs frontaliers ne sont pas sous son contrôle. Et ils le sont rarement dans un grand centre de données.

La plupart des autres services du NGFW n'ont qu'une valeur limitée pour les liaisons est-ouest ou sud-nord. Le DDoS et le QoS n'ont guère de sens à l'intérieur d'un réseau. De même, un logiciel AV moderne fonctionnant au sein du système d'exploitation est probablement plus efficace qu'une solution basée sur le réseau, de sorte que l'antivirus basé sur le réseau n'est probablement pas à l'ordre du jour.

Les performances des fonctionnalités du NGFW sur les appareils d'extrémité

Il est temps de parler des implications en termes de performances des fonctions NGFW exécutées sur les terminaux. Si vous vous souvenez, la première partie mentionnait que les appliances NGFW étaient presque des systèmes de classe supercalculateur avec beaucoup de matériel spécialisé pour obtenir des performances respectables. Il s'ensuit évidemment qu'une pénalité de performance substantielle serait imposée aux serveurs individuels lors de la mise en œuvre de la même fonctionnalité. Heureusement, il semble que ce soit l'un de ces moments où l'intuition fait défaut. Expliquons 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 et qu'il est l'une des raisons de la grande quantité de silicium personnalisé dans un appareil NGFW. Si je protège un centre de données de taille moyenne de 1 000 charges de travail avec 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 (plus éventuellement Solaris ou AIX, si je travaille dans le secteur de la santé ou de la banque). Chacun de ces 1 000 serveurs exécute au moins un service que je dois surveiller, voire jusqu'à trois ou quatre services différents, qui présentent tous des vulnérabilités potentielles. Et avec une douzaine de systèmes d'exploitation, je pourrais utiliser une douzaine de versions différentes de chacun de ces trois ou quatre services, chacun présentant des vulnérabilités différentes.

En bref, j'attends entre 10 000 et 100 000 signatures de vulnérabilités pour ces milliers de machines. Et je cherche des signes de ce type dans chaque paquet qui passe par mon dispositif réseau NGFW - sur tous les ports possibles qu'ils peuvent utiliser. Ce n'est clairement pas une charge que nous voulons imposer à chaque serveur du centre de données.

Dans la pratique, ce n'est pas nécessaire. Il n'y a aucune raison de rechercher les vulnérabilités de 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 de l'application X version 1.0, 1.1, 1.2, 1.3, 2.0, 2.1 sur un système utilisant l'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 ? En effet, grâce à la présence d'un agent sur chaque serveur, nous avons un accès complet au système d'exploitation, aux correctifs appliqués ou non, aux logiciels (et à leurs versions) installés et en cours d'exécution, ainsi qu'aux ports sur lesquels ils communiquent. Nous recherchons des vulnérabilités spécifiques au système d'exploitation et aux versions logicielles 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 spectaculairement grand 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 sur chaque serveur pour détecter les contenus DLP restreints, ni de détenir des bases de données massives d'URL ou d'informations IP pour les adresses publiques sur chaque serveur. Dans le cas de la DLP, vous ne recherchez qu'un contenu spécifique sur un ensemble très précis de serveurs, sur la base d'é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 grande base de données des caractéristiques IP peut être conservée dans le système central de gestion des politiques, récupérée au besoin via une connexion LAN à faible latence et mise en cache localement pour les consultations ultérieures. La plupart des serveurs communiquent sans cesse avec le même ensemble relativement restreint de serveurs.

Fonctionnalités du NGFW pour une solution de microsegmentation

Lorsque vous ajoutez des fonctionnalités NGFW à une solution de microsegmentation, l'un des avantages les plus importants 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 ou des sous-réseaux entiers en tant que groupe. Une politique basée sur les é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ù c'est nécessaire, au lieu de peindre le centre de données avec un pinceau large. Des fonctions spécifiques du NGFW peuvent être activées uniquement pour les serveurs nécessaires, et uniquement pour effectuer l'inspection requise. Cela permet de limiter les frais généraux au strict minimum nécessaire pour répondre à vos besoins spécifiques en matière de sécurité et de trouver un équilibre entre la sécurité, les performances et les coûts.

N'oubliez pas que l'objectif ici n'est pas de remplacer vos dispositifs NGFW frontaliers. Il s'agit plutôt de combler de manière sélective les lacunes là où les solutions NGFW existantes n'ont pas de sens sur le plan architectural ou financier, avec un sous-ensemble puissant de fonctions NGFW fonctionnant 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 d'offrir ces fonctionnalités dans des situations où les solutions traditionnelles seraient trop coûteuses.

Perspectives d'avenir

Pour conclure, regardons encore plus loin dans l'avenir.

TLS 1.3 a été ratifié en 2018 et devient peu à peu la prochaine norme pour les services web et autres services cryptés. Votre première réaction à ce sujet pourrait être : "Ce n'est pas mon problème" ou "Et alors ?". Je dirais que c'est en fait extrêmement pertinent. Un NGFW ne peut pas fournir la plupart des services disponibles sans inspection approfondie des paquets (DPI). Et pour que l'IAP ait un sens, les données doivent être en clair, et non cryptées.

Lorsque les NGFW ont fait leur apparition sur le marché, seule une infime partie 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 l'ensemble du trafic web est crypté et ne peut donc pas être analysé à la recherche de logiciels malveillants, de virus, d'exfiltration de données ou de tout autre serveur NGFW. La solution développée à cet effet est appelée TLS MiTM (man-in-the-middle).

La mise en place de TLS MiTM est un peu fastidieuse, bien que le 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.) au sein 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 dispositifs NGFW de votre périmètre, qui sont configurés comme des proxys web transparents.  

Lorsqu'un utilisateur (ou un serveur ou tout autre appareil) établit une connexion sortante avec un site web externe, disons gmail.com pour cet exemple, au lieu d'utiliser le certificat TLS de Google, il chiffre le trafic avec le certificat interne de l'organisation. Lorsque le NGFW du périmètre voit ce trafic sortant, il est en mesure de le décrypter et d'en analyser entièrement le contenu, puisqu'il possède une copie de la clé privée. Le NGFW met fin à la connexion interne et établit une nouvelle connexion TLS avec gmail.com à l'aide du certificat Google, et transmet le contenu des deux connexions (la connexion interne depuis l'intérieur de l'organisation vers la connexion externe avec gmail), ce qui lui permet de voir et d'analyser l'ensemble du trafic, même s'il est crypté.

Bien que lourde et gourmande en ressources humaines, cette méthode a fonctionné raisonnablement bien pour la plupart des services pendant une dizaine d'années en utilisant SSL, puis TLS 1.0, 1.1 et 1.2.

Jusqu'à présent, 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 dispositif passif n'a aucun moyen de décrypter la charge utile, même s'il a accès à la clé privée utilisée. Avec TLS 1.3, il est obligatoire d'insérer un dispositif dans le flux et d'utiliser un proxy pour le trafic. Deuxièmement, TLS 1.3 déprécie les algorithmes de chiffrement de moindre sécurité, ce qui supprime la possibilité pour un dispositif proxy de rétrograder une connexion proxy à TLS 1.2, une stratégie souvent employée pour économiser des ressources de calcul dans le NGFW (car les algorithmes de chiffrement de moindre sécurité requièrent généralement moins de calculs).

Si l'histoire de la cryptographie nous a appris quelque chose, c'est que les normes anciennes et fiables ont tendance à se révéler vulnérables au fil du temps avec une certitude proche de 100%. La pratique actuelle consistant à rétrograder TLS 1.3 vers TLS 1.2 pour permettre le déchiffrement passif et/ou la rétrogradation pour économiser des ressources est en sursis, en attendant que TLS 1.2 soit dépassé. Lorsque ce jour viendra, un grand nombre de dispositifs d'inspection passive deviendront de coûteux presse-papiers, tandis que de nombreuses solutions en ligne seront rapidement dépassées du fait qu'elles seront obligées d'utiliser une cryptographie plus coûteuse en termes de calcul.

Un petit secret du monde NGFW est que, du moins au moment où nous écrivons ces lignes, votre trafic WebSocket n'est probablement pas inspecté pour détecter des menaces de quelque nature que ce soit. Pourquoi ? Parce qu'un NGFW classique ne peut pas décrypter 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écrypté après coup à l'aide d'un logiciel comme Wireshark (en supposant que vous disposiez des clés privées) afin d'inspecter la charge utile. Les WebSockets sont de plus en plus répandues dans les applications web, car cette technologie offre une solution idéale aux applications JavaScript pour transférer des données entre votre navigateur et un serveur web. Il est possible de déplacer littéralement n'importe quoi par le biais d'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 TLS), soit permettre au trafic de passer sans être inspecté. La première solution réduit la qualité de l'expérience utilisateur et la seconde expose l'organisation à des risques. Ni l'un ni l'autre n'est idéal.

Le traitement de certaines tâches NGFW au niveau de la charge de travail permet de 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 calcul en les traitant par charge de travail. Le client peut ainsi se décharger d'une partie de la charge utile d'inspection de ses dispositifs de réseau, ce qui retarde la mise à niveau d'un pare-feu qui serait autrement nécessaire, tout en apportant les avantages de la confiance zéro à des parties de son réseau qui n'auraient peut-être pas été techniquement ou financièrement viables.