La (micro)segmentation d'un point de vue pratique

Avant d'évoquer les meilleures pratiques et stratégies, nous devons d'abord définir notre environnement. La segmentation du réseau implique de « diviser » le réseau en parties (segments) et de définir qui peut accéder à quoi, et de quelle manière (par exemple, les serveurs Web ne peuvent être accessibles que via HTTP/S). 

Jusqu'à présent, les VLAN et les pare-feu physiques permettaient de le faire, mais récemment, nous avons vu de plus en plus d'approches logicielles des pare-feu et de la segmentation (Akamai Guardicore Segmentation, par exemple). Nous ne recommanderons pas une approche ou une autre, car les deux approches présentent des avantages et des inconvénients. Nos règles et stratégies recommandées sont indépendantes et peuvent s'appliquer partout.

Lorsque vous passez du contrôle du trafic à l'aide de VLAN, de listes de contrôle d'accès (ACL) et de plages d'adresses IP à l'utilisation d'étiquettes personnalisées indépendantes, vous entrez dans le domaine de la microsegmentation. Toutes nos stratégies dans cet article de blog supposent que nous utilisons la microsegmentation.

Il devrait être possible d'adapter les stratégies et les directives pour que la segmentation ne soit pas nécessaire, mais le processus de définition de tous les VLAN, ACL et listes d'adresses IP, puis de leur maintenance, est vraisemblablement irréaliste ou entraînera l'épuisement immédiat de tous les administrateurs et ingénieurs réseau. (Essayez de définir la plage/le groupe d'adresses IP de tous les serveurs de finance. Cela peut sembler réalisable, mais parviendrez-vous à maintenir cette liste avec précision pendant longtemps ? Il ne s'agit que d'un seul groupe de serveurs ; dans un réseau d'entreprise, vous en aurez beaucoup plus : utilisateurs finaux, contrôleurs de domaine, administrateurs de domaine, imprimantes, etc.)

Avant d'aborder la segmentation, nous devons discuter d'une condition préalable majeure pour y parvenir : la visibilité. La microsegmentation n'est pas isolée. Vous ne pouvez pas protéger ce que vous ne pouvez pas identifier. Une bonne segmentation n'est efficace qu'en parallèle d'une visibilité du réseau qui organise et résume le trafic. Il y a généralement trop de trafic pour analyser de manière réaliste toutes les données de façon brute à l'œil nu.

Avant de nous lancer véritablement dans les stratégies de segmentation, nous aimerions aborder certaines directives, ou certains principes, que nous croyons être cruciaux pour une bonne segmentation.

De manière générale, les serveurs qui ont beaucoup de trafic entrant sont davantage axés sur la gestion des requêtes, comme les serveurs Web ou de fichiers (même les contrôleurs de domaine entrent dans cette catégorie). Par conséquent, ils ne devraient pas générer beaucoup de trafic sortant, ou au moins celui-ci devrait être strictement défini. 

En outre, avec des restrictions minimales sur la sortie et l'entrée, le serveur court le risque d'être utilisé comme pivot par les pirates, car les serveurs sont plus accessibles pour ces derniers et peuvent être utilisés pour accéder à une partie plus large du réseau.

Pour certaines machines, les règles doivent être souples, car il y a trop de variabilité dans le trafic sortant de la machine ; par conséquent, de nombreuses exceptions doivent être faites. 

Prenons, par exemple, les serveurs de jump box : différents utilisateurs les utilisent pour se connecter à différents serveurs avec des protocoles différents. Vous ne pourrez pas couvrir tous les cas d'utilisation sans être trop permissif (ce qui va à l'encontre du but principal de la segmentation). 

Dans de tels cas, nous croyons qu'il est préférable d'employer d'autres mécanismes de défense et de les rendre plus stricts (comme l'utilisation d'un contrôle d'accès utilisateur renforcé dans l'exemple des jump box, ou des seuils d'alerte plus bas pour les services de surveillance).

Ce n'est pas parce qu'un flux de trafic existe déjà lorsque vous commencez à segmenter que vous devez l'autoriser. Parfois, vous devrez modifier les configurations existantes d'applications ou de serveurs lorsque vous déciderez que le trafic qu'ils produisent est inutile. Et parfois, vous devrez également consulter les configurations existantes pour comprendre pourquoi un trafic spécifique existe.

Dans ce cas, la segmentation est identique à un pare-feu traditionnel : vous bloquez le trafic entrant de l'extérieur de votre réseau qui ne doit pas entrer. Ce trafic provient généralement d'Internet, mais peut également provenir de réseaux tiers connectés au vôtre. 

Par conséquent, le blocage des ports exposés SSH (Secure Shell) ou RDP (Remote Desktop Protocol), ou n'importe quel port de la section mouvements latéraux , est conseillé. En réalité, il est préférable d'utiliser une liste blanche plutôt qu'une liste noire pour le trafic provenant de l'extérieur de votre réseau, en particulier d'Internet (par exemple, envisagez le nombre de scanners Internet actifs à tout moment).

Bien entendu, comme pour tout autre outil de sécurité, la segmentation des pratiques (ou des règles) n'est pas un fourre-tout en matière de menaces. Dans ce cas, la segmentation ne peut pas couvrir tous les vecteurs d'accès initial, et s'appuyer uniquement sur la segmentation expose votre réseau à des risques. De nombreuses intrusions commencent par des e-mails d'hameçonnage, des liens ou d'autres formes d'ingénierie sociale. 

Certaines intrusions commencent également par des vulnérabilités dans les protocoles qui devraient être autorisés, ou par des identifiants faibles au sein des services qui sont légitimement exposés à Internet, comme le serveur VPN. Pour cette raison, nous vous recommandons de ne pas utiliser uniquement la segmentation pour empêcher l'accès initial, et d'employer des solutions de sécurité pour la protection de l'hôte et de la messagerie en plus de la segmentation.

Il existe de nombreuses façons d'exécuter des mouvements latéraux ; nous ne les aborderons pas toutes. Plus précisément, nous nous intéresserons à la prévention des mouvements latéraux qui peuvent se produire via des processus légitimes qui existent déjà sur la machine, en utilisant des protocoles comme RDP ou SSH, des services basés sur RPC comme le gestionnaire de services ou le planificateur de tâches, des outils de gestion comme PowerShell ou WMI, ou certains des protocoles et outils disponibles dans Linux que nous avons abordés dans un autre article de blog.

Nous n'évoquerons pas les vulnérabilités One Day ou Zero Day, car elles peuvent s'appliquer à n'importe quel produit et présenter des mises en œuvre différentes. Il est donc impossible de créer une stratégie globale qui s'applique à elles. La seule chose que nous pouvons vous recommander est la segmentation, car un élément inaccessible reste beaucoup plus difficile à exploiter.

Avant de nous plonger dans les différents facteurs des différents protocoles, deux principes s'appliquent à chacun d'eux.

Les utilisateurs n'ont pas vraiment besoin d'accéder aux machines des autres utilisateurs, surtout pas via le réseau. À moins qu'un utilisateur appartienne au service informatique, peu de choses justifient sa connexion à distance à la machine d'un autre utilisateur. Par conséquent, il devrait être assez simple de restreindre le trafic entre les machines des utilisateurs sans risque de beaucoup compromettre l'exploitation du réseau.

En outre, les protocoles abordés dans cette section pouvant être utilisés pour le contrôle ou l'exécution à distance, ils peuvent également servir de vecteurs d'accès initial. C'est pourquoi nous réitérons la nécessité de restreindre l'accès arbitraire à Internet sur ces protocoles.

Comme ces services sont interactifs et graphiques, leur utilisation automatisée est assez limitée. Par conséquent, vous êtes susceptibles de ne pas voir les serveurs utiliser ces protocoles très souvent (par contre, si vous découvrez ces protocoles, cela signifie que le moment est venu d'enquêter). 

Le même raisonnement s'applique aux machines des utilisateurs : ces derniers ne devraient pas avoir besoin de se connecter les uns aux autres. Les exceptions à ces hypothèses peuvent être les jump box et les serveurs de terminaux qui permettent aux utilisateurs d'accéder à des environnements ou des serveurs, les connexions du personnel informatique aux machines des utilisateurs ou les propriétaires d'applications se connectant au serveur d'applications. 

La gestion de ces exceptions doit se faire en créant des règles appropriées utilisant la segmentation, mais ces efforts doivent également être complétés par des solutions appropriées de gestion des accès et des identités (IAM).

Bien que le concept du protocole SSH soit similaire à celui des RDP, le sujet est un peu plus complexe. Puisque SSH est basé sur un terminal (texte), il est beaucoup plus facile de l'utiliser pour interagir avec les logiciels, et il existe des programmes et des scripts qui l'utilisent. En plus de cela, SSH est également utilisé pour intégrer des protocoles moins sécurisés, comme SFTP, qui est l'encapsulation SSH du protocole de transfert de fichiers.

Pour ces raisons, SSH nécessite une approche beaucoup plus granulaire que les autres RDP. Sans une visibilité adéquate du trafic réseau, il sera très difficile de segmenter correctement SSH sans affecter les utilisateurs finaux ou l'exploitation du réseau.

MS-RPC et SMB n'autorisent pas immédiatement les mouvements latéraux, car d'autres protocoles construits sur leur base l'autorisent (voir la Figure 4). SMB est utilisé pour le transfert de fichiers et les communications, tandis que RPC est utilisé pour appeler des fonctions distantes à partir d'interfaces définies. RPC étant également parfois transporté par SMB, ils sont donc étroitement associés. Ils sont également réputés difficiles à segmenter correctement, car ils sont intégrés dans le système de domaine Windows. 

Par exemple, l'authentification de domaine est mise en œuvre dans Netlogon, un protocole basé sur RPC. Les règles de groupe de domaines et les scripts de connexion sont stockés dans un dossier partagé sur le contrôleur de domaine appelé SYSVOL, et les machines associées aux domaines y accèdent via SMB.

Bloquer SMB et RPC est pratiquement impossible, sans éliminer le domaine entier. Alors, que pouvez-vous faire ? Avec SMB, vous pouvez créer des règles basées sur des unités logiques : la plupart des serveurs et des machines ne devraient pas communiquer entre eux via SMB, sauf si la destination est un serveur de fichiers. En tant que telle, une segmentation appropriée de cloisonnement devrait permettre d'atténuer le risque de SMB.

Une approche similaire peut être appliquée à RPC, mais elle peut être encore plus restrictive, car nous n'avons pas besoin d'autoriser le trafic RPC vers les serveurs de fichiers, contrairement à SMB. En outre, puisque RPC est géré en mode utilisateur, il est possible de créer des règles de segmentation basées sur le service ou le processus cible. Vous n'avez donc qu'à gérer les interfaces RPC qui peuvent être utilisées de manière abusive pour les mouvements latéraux (et uniquement si vous disposez d'un agent de segmentation capable de gérer les règles basées sur les processus ou les services). 

Le tableau suivant montre les interfaces RPC qui doivent être gérées pour empêcher tout mouvement latéral.

Dans la mesure où toutes les opérations effectuées sur ces interfaces RPC ne sont pas malveillantes (par exemple, certaines solutions ou outils de surveillance interagissent avec le gestionnaire de services à distance pour vérifier l'intégrité du service), nous vous recommandons d'analyser les communications RPC existantes. Si elles ne sont normalement pas accessibles à distance (ou si vous pouvez restreindre la liste des sources), nous vous conseillons de créer des règles de segmentation autour d'elles pour profiter d'un avantage supplémentaire en matière de sécurité.

PowerShell et WMI sont capables d'interagir avec des machines distantes, et cette interaction est « optimisée » par Windows Remote Management (WinRM). Comme l'utilisation légitime est généralement la gestion ou la surveillance à distance (avec WMI), les cas d'utilisation devraient être peu nombreux sur votre réseau. Il devrait être possible de créer des règles de segmentation qui restreignent l'utilisation arbitraire et ne l'autorisent qu'à partir de serveurs de surveillance ou de machines informatiques. 

Bien sûr, des valeurs aberrantes sont possibles et nous avons découvert quelques cas où PowerShell distant était largement utilisé par les développeurs par commodité. Cela nécessiterait probablement une décision au cas par cas.

À moins de vouloir contrôler tout le trafic sortant comme en 1984, vous ne pouvez pas raisonnablement vous attendre à empêcher l'exfiltration des données lors d'attaques utilisant uniquement la segmentation. Internet est grand et vaste, et il n'est pas réaliste de disposer d'un jugement précis pour chaque site et chaque serveur auxquels les utilisateurs se connectent à partir de votre réseau. En tant que tels, les acteurs malveillants peuvent facilement camoufler leurs tentatives d'exfiltration parmi tous les autres trafics sortants.

Au lieu de tenter de contrôler le trafic sortant, il est plus simple de contrôler qui peut accéder aux données sensibles. Les serveurs du réseau sont le seul endroit où il pourrait être possible de restreindre le trafic sortant, car à la différence des machines des utilisateurs, il devrait y avoir beaucoup moins de variabilité dans leurs destinations sortantes.

Le principe fondamental de toute cette section est « Ce n'est pas parce que cela existe que cela doit être autorisé. » Lors de la segmentation d'une partie du réseau, qu'il s'agisse d'une application stratégique (comme SWIFT), d'une unité opérationnelle (comme le contrôleur de domaine) ou d'un environnement (comme les serveurs de production), la première chose à faire est d'analyser le trafic existant (Figure 5). 

Après cette analyse, vous pouvez créer des règles qui autorisent les flux pertinents et limitent le reste (c'est également l'occasion de détecter des erreurs de configuration qui devraient être gérées par le propriétaire de l'application au lieu de la segmentation). 

Nous vous recommandons de ne pas mettre en œuvre de règle de blocage immédiatement, mais de l'exécuter en mode alertes uniquement pendant un certain temps. Vous ne devez passer à une règle restrictive qu'après avoir estimé que la règle s'exécute comme prévu et que les alertes de violation de règle sont à un niveau minimal ou contrôlé. 

Il est également important de différencier votre environnement actuel (celui qui existait avant que vous ne commenciez à le segmenter) et votre environnement futur (celui après la mise en œuvre de votre règle de segmentation). Lors de la première mise en œuvre de la segmentation, vous devez faire preuve de prudence et vous renseigner sur le réseau afin de ne rien « abimer ». 

De nouveaux éléments, cependant, doivent être ajoutés tout en tenant compte de la règle de segmentation existante. Réalisez des exceptions et des allocations de règle le cas échéant pour bénéficier d'une exploitation normale, mais ne négligez pas la règle existante simplement parce que vous étendez le réseau.

Avec le cloisonnement, nous nous intéressons surtout aux interfaces du segment concernant le reste du réseau et le monde. Nous voulons contrôler ce qui entre et sort de la partie du réseau que nous voulons segmenter sans tenir compte de ce qui se passe à l'intérieur du segment.

Nous pouvons aller encore plus loin dans le cloisonnement et appliquer des règles à des machines individuelles en fonction de leur utilisation. Ainsi, par exemple, si un serveur fonctionne uniquement comme une base de données, il ne devrait avoir accès qu'aux ports de la base de données, et un serveur Web aux ports Web.

Bien évidemment, les choses ne sont pas aussi simples. Il y a généralement plus de services qui ont besoin d'accéder à ces serveurs, tels que des outils de surveillance, des moniteurs de performances ou les équipes informatiques. Habituellement, ces ports d'accès sont également très semblables aux techniques de mouvements latéraux, dans la mesure où ils sont généralement basés sur une sorte de contrôle à distance. (Par exemple, les outils de surveillance à distance interrogent le gestionnaire de services, de la même manière que la technique de mouvements latéraux de PsExec. La seule façon de distinguer les appels est l'inspection approfondie des paquets, qui n'est généralement pas disponible.)

Pour surmonter ce défi, chaque fois que vous avez besoin d'autoriser un trafic supplémentaire en plus de l'accès normal au service, nous vous recommandons de limiter les sources autorisées au segment qui devrait effectuer la surveillance.

De plus, nous pouvons limiter l'accès des utilisateurs aux emplacements sensibles dont ils n'ont pas besoin. Si la base de données est utilisée uniquement par des applications internes, il y a peu de raisons de laisser des utilisateurs arbitraires l'interroger. Selon nous, bloquer l'accès des utilisateurs arbitraire est l'étape de sécurité la plus cruciale, car de nombreuses attaques commencent par des utilisateurs compromis.

Avec la microsegmentation, nous appliquons une autre couche de granularité à notre règle de segmentation, c'est-à-dire que nous séparons les machines du segment en fonction de leur rôle ou de leur sensibilité. Nous pouvons considérer cela comme une approche hybride entre le cloisonnement des applications et le cloisonnement général. La principale différence par rapport au cloisonnement est que nous contrôlons désormais également le trafic à l'intérieur du segment et ne faisons pas automatiquement confiance aux voisins.

Notre principe ici est que nous ne devons pas faire confiance au trafic des machines voisines simplement parce que nous sommes dans le même segment. Les pirates utiliseront toutes les connexions possibles pour s'infiltrer dans tout le réseau, quels que soient les segments. 

Par conséquent, même si nous avons le même type de serveur d'applications dans le segment, il n'y a aucune raison pour qu'ils puissent communiquer entre eux sur chaque port et protocole. La microsegmentation signifie que nous appliquons des règles sur tous les types de trafic, même à l'intérieur du segment réseau et entre les machines ayant le même rôle.

Bien sûr, les machines à l'intérieur d'un même segment sont généralement plus étroitement associées, et il est donc plus difficile d'ajouter des règles sans être trop permissif.

En fonction de la manière dont vous définissez les segments de votre réseau, les principes du cloisonnement des applications peuvent souvent également s'appliquer en tant que principes de microsegmentation. Par exemple, si nous divisons notre réseau en un segment utilisateur, un segment base de données et un segment serveur Web, alors les principes définis dans le cloisonnement des applications conviendront également à la microsegmentation. Le seul ajout nécessaire est l'application des mêmes principes à l'intérieur de chaque segment d'application, entre différentes machines.

Cependant, si notre réseau est divisé en un segment finance, un segment ventes et un segment informatique, et que chaque segment comprend une combinaison de serveurs et de machines utilisateurs, nous devons alors être plus créatifs. Après avoir appliqué les stratégies de cloisonnement général aux segments, nous devons ensuite nous tourner vers la création de règles entre les segments et à l'intérieur d'eux. Nous pouvons considérer chaque segment comme un mini-réseau, puis diviser chaque segment en différentes applications et différents types de machines qui le composent. (Par exemple, pour un segment ventes, nous pouvons avoir un serveur de fichiers, une base de données et des machines utilisateurs.) Nous pouvons gérer chaque type de machine comme un nouveau segment, et suivre à nouveau les directives de cloisonnement ou de cloisonnement des applications.

La Figure 6 résume les relations entre les différentes stratégies de segmentation.

La segmentation du réseau est un outil destiné à renforcer la sécurité du réseau et à faire face aux menaces qui pèsent sur celui-ci. C'est également un outil qui peut fournir une valeur immédiate en matière de sécurité, dans la mesure où vous n'avez pas à initier de projets de segmentation longs ou difficiles, mais aussi diviser votre travail en plusieurs sous-projets, chacun améliorant la sécurité du réseau étape par étape. 

Nous avons fourni des directives à diverses règles et stratégies de segmentation pour aider les administrateurs réseau à accomplir leurs objectifs. Nous espérons que nos recommandations sont pratiques et permettront aux entreprises de garantir une meilleure sécurité.

Le groupe Security Intelligence d'Akamai continuera de surveiller, d'étudier et de publier des recherches sur une multitude de sujets liés à la sécurité. Pour bénéficier de mises à jour en temps réel et d'autres études de pointe, suivez-nous sur Twitter !