Sécurité

La micro-segmentation au service de la LPM

Share this post:

La Loi de programmation militaire impose aux Opérateurs d’importance vitale de mettre en œuvre des règles de cloisonnement et de filtrage. La micro-segmentation répond à ces enjeux, tout en restant plus agile que le cloisonnement réseau traditionnel.

Dans le domaine de la cybersécurité, la Loi de programmation militaire (LPM) a des conséquences sur les Opérateurs d’importance vitale (OIV). Entre autres choses, elle impose de mettre en œuvre des mesures de cloisonnement (règle n°16), de filtrage (n°17) et de cartographie (n°3) des Systèmes d’information d’importance vitale (SIIV). Ces exigences se retrouvent peu ou prou dans d’autres textes de l’Agence nationale de la sécurité des systèmes d’information (Anssi). Si la LPM n’impose pas de solutions spécifiques, elle suppose de définir des approches comportant les éléments d’architectures aptes à répondre aux différentes exigences. Il est ainsi demandé d’assurer le cloisonnement des systèmes d’information d’importance vitale (SIIV) vis-à-vis de l’extérieur, à savoir des autres composantes du système d’information (SI) de l’opérateur, des composants tiers, et de cloisonner les sous-systèmes du SIIV entre eux (autrement dit, isoler les briques logicielles).

 

S’adapter à un environnement technologique changeant

Le besoin de compartimenter les échanges d’information sur un réseau n’est pas nouveau. Les premières solutions sont en effet apparues à la fin des années 80, sous forme de pare-feux logiciels ou physiques. Ces solutions, toujours utilisées aujourd’hui, sont extrêmement efficaces à condition d’être correctement configurées et administrées. La protection d’un SI peut en effet demander de mettre en œuvre plusieurs milliers, voire dizaine de milliers, de règles de filtrage.

Si cette approche traditionnelle est pertinente pour des environnements simples et qui évoluent peu, elle s’avère toutefois extrêmement limitée pour protéger des infrastructures plus complexes. La montée en puissance du Cloud et l’avènement de nouvelles manières de penser une infrastructure, à l’instar de la conteneurisation qui repose sur la création et suppression de centaines de machines virtuelles, a rendu nécessaire la création d’approches plus agiles.

Ce constat a donné naissance à une nouvelle technique de cloisonnement : la micro-segmentation. Son objectif est de permettre la création de règles de sécurité directement au niveau d’un workload. Cette approche est généralement peu intrusive et cherche à limiter les changements importants (conservation de l’adressage IP, utilisation de composants natifs…). De ce fait, la micro-segmentation permet de s’affranchir des contraintes techniques liées à l’infrastructure sous-jacente et lie le déploiement des politiques de sécurité au déploiement applicatif.

La micro-segmentation ne repose pas sur une technologie unique et les éditeurs proposent au contraire des approches diversifiées : la solution Cisco Tetration s’appuie ainsi sur des appliances, physiques ou virtuelles, au niveau du réseau ; VMWare NSX utilise les fonctionnalités d’un hyperviseur ; Palo Alto Networks cloisonne selon l’utilisateur grâce à un référentiel d’identités.

Quelle que soit la technologie retenue, la micro-segmentation s’inscrit dans le modèle de l’Infrastructure As Code, à savoir un modèle architectural qui s’appuie sur des scripts qui sont interprétés pour provisionner des infrastructures. Pour y parvenir, les outils de micro-segmentation permettent à l’utilisateur de manipuler les règles de sécurité avec un métalangage, proche du langage naturel. Elles peuvent ainsi être intégrées à une démarche DevOps, en permettant aux équipes métier de créer leurs règles puis de les implémenter de manière programmatique.

La micro-segmentation n’est néanmoins pas une fin en soi. L’évolution des techniques et des besoins fait émerger de nouvelles approches, qui pourraient s’avérer tout aussi pertinentes. Parmi les dernières tendances, on trouve ainsi la nano-segmentation, qui opère un cloisonnement non plus au niveau applicatif mais au niveau des processus.

 

Retour d’expérience : utiliser la micro-segmentation pour atteindre les objectifs de la LPM

En 2018, nous avons contribué à la conception et la mise en œuvre de solutions pour répondre aux exigences de cloisonnement et de filtrage de la LPM pour le compte d’une grande banque française, à la fois banque d’investissement et banque de détail. Cette mission a demandé d’adopter des approches distinctes, car les métiers, cultures et donc les SI du client sont différents. Pour la banque de détail, le SI est ainsi segmenté au niveau réseau et bien compartimenté, avec de multiples pare-feux. Côté banque d’investissement, nous avons trouvé au contraire un réseau plutôt plat, avec moins de pare-feux. Ceci s’explique par les spécificités de l’activité banque d’investissement, qui nécessitent en général plus de réactivité. Celles-ci pourraient être entravées par la lourdeur de la gestion des règles de filtrage des pare-feux.

Nous avons retrouvé cette diversité au niveau des environnements techniques. Le SI du client est ainsi constitué de serveurs physiques (accueillant Sun Solaris, IBM AIX, etc.) mais aussi de serveurs virtuels dans un datacenter privé et de mainframes IBM.

Pour les mainframes, une solution spécifique a été mise en œuvre pour respecter la LPM. Pour le reste du SI, une méthode bien connue est de créer des DMZ, avec réseau spécifique physique ou virtuel (VLan) et pare-feu. Cette solution convenait pour les applications déjà bien cloisonnées (notamment celles correspondant à l’activité de banque de détail). Pour les autres applications, une étude nous a convaincus que cette approche traditionnelle serait très coûteuse, avec un risque opérationnel élevé, et des délais trop longs. Nous avons donc opté pour une technologie plus innovante : la micro-segmentation.

Nous avons choisi une technologie de micro-segmentation s’appuyant sur la cryptographie et intégrée au niveau de l’OS. Plus précisément, nous employons la solution d’une licorne de la Silicon Valley, Illumio. Leur solution Illumio ASP (pour Adaptative Security Platform) permet une certaine granularité, car la micro-segmentation s’effectue au plus près des workloads et donc des applications. Elle permet de répondre aux exigences de filtrage et de cloisonnement (logique en l’occurrence, par le chiffrement) avec pour avantage d’être mieux alignée avec les orientations actuelles des DSI, qui cherchent à migrer dans le Cloud tout leur SI à l’horizon 2020.

 

Convaincre l’Anssi

Si la LPM laisse le choix dans les solutions à mettre en œuvre, l’Anssi propose des bonnes pratiques qu’il est judicieux de respecter. L‘Anssi estime ainsi que les VLan ne sont pas suffisants dans le cadre de la LPM : il faut y ajouter une couche de chiffrement. L’un des challenges posés par le choix d’Illumio était que son éditeur, jeune entreprise américaine, n’était pas connu de l’Anssi. L’agence de sécurité s’est donc renseignée sur l’éditeur et a porté une attention particulière sur le fonctionnement de son module de cloisonnement par chiffrement, moins connu que le cloisonnement réseau. Illumio s’appuie en effet sur le pare-feu natif et monte des tunnels IPSec pour sécuriser les échanges d’informations. Cette fonctionnalité a été appréciée par l’agence, tout comme la partie cartographie d’Illumio ASP, qui facilite l’élaboration puis la mise en œuvre des règles de filtrage.

En savoir plus : https://www.ibm.com/fr-fr/security

 

Article publié par le Journal du Net.

 

Consultant en Sécurité IBM

More Sécurité stories
12 juin 2024

Simplifier les déclarations liées à la CSRD grâce aux nouvelles fonctionnalités d’IBM®Envizi™

IBM a le plaisir d’annoncer la prise en compte de la directive européenne (CSRD) dans le module « sustainability reporting manager » d’IBM® Envizi™. Cette considération aidera les entreprises à répondre aux exigences de reporting de la directive européenne (CSRD). La CSRD impose aux entreprises de fournir des informations et des indicateurs définis via les […]

Continue reading

12 juin 2024

Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (2/2) ?

Dans notre article « Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (1/2) ? », nous avons présenté les différentes étapes du pré-assessment technique qui consiste à analyser l’ensemble des applications du patrimoine applicatif. Dans cette seconde partie, nous allons détailler l’assessment technique à réaliser pour chacune des applications.   Phase […]

Continue reading

12 juin 2024

Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (1/2) ?

Contrairement aux applications conçues et développées spécifiquement pour un environnement cloud, un parc applicatif « on premises » a généralement été bâti au fil du temps, avec des technologies datant d’époques différentes. Il est par nature plus ou moins hétérogène. Pour différentes raisons (par exemple la scalabilité horizontale et verticale de manière automatique en fonction du besoin, […]

Continue reading