Retour d’expérience (REX): Comment garantissez-vous l’efficacité des mesures de sécurité de vos équipements de sécurité périmétriques ? – Partie 1

Cybersécurité Sid Ahmed Djellali 23/12/2021 298 5

Depuis plusieurs années, Cyberdian © accompagne plusieurs grand compte pour déployer un outil de gestion et d’orchestration des politiques de sécurité réseau (Onpremise & Cloud) notamment un grand compte du secteur financier (500 équipements, 3 workflows, 600 applications business), on vous explique comment ici.

1. Qu’est-ce qu’un équipement de sécurité périmétrique ?

Elément incontournable et essentiel à la défense d’un système d’informatique qu’il soit sur site (on premise) ou sur le cloud, un pare-feu (firewall) est une barrière sur les canaux de communication de votre trafic réseau qui permet de protéger des accès non maitrisés. Cet élément historique de la sécurité du système d’information a connu de nombres évolutions techniques depuis plus d’une trentaine d’années. Ainsi le pare-feu qui était à la base un simple élément filtrant de communication, s’intègre aujourd’hui dans un ensemble plus vaste qu’on peut qualifier de sécurité défensive en profondeur (defense in depth) – Concept emprunté aux militaires (comme beaucoup de choses en cybersécurité)

L’ensemble des pare-feu du marché sont dit « à état (statefull) » et gèrent les couches 3 et 4 du modèle OSI et apporte ainsi un premier niveau de défense périmétrique et permet donc :

De segmenter son réseau en zone de sécurité
- Zone démilitarisée (DMZ) pour les zones de sécurité avec une exposition internet
- Zone pour les zones de sécurité interne
De contrôler les accès aux ressources/services dans des zones de sécurité

D’autres fonctions portées par cette brique d’infrastructure (le pare-feu) peuvent :

soit améliorer la sécurité défensive en profondeur :
- Intrusion Prevention System (IPS)
- Web Application Firewall (WAF) ou Application Control (AC) – Gestion de la couche 7 du modèle OSI
- Antivirus (AV)
- Proxy Internet
soit apporter de nouveaux usages :
- Virtual Private Network (VPN)
- Serveur DNS
- SD-WAN

L’ensemble des contrôles sur les canaux de communication sont appliqués sur chaque pare-feu dans des règles de sécurité qui composent les politiques de sécurité réseau (Network Security Policy). De manière générale, on retrouve 2 à 3 éditeurs de solution sur un système d’information lambda (à minima 1 ou 2 pour les architectures de point d’accès internet [PAI] et 1 autre comme le réseau interne).

Ces politiques de sécurité réseau qui existent de manière indépendante dans chaque pare-feu ont eu une raison d’être à un moment d’année de leur existence.

Mais comment garantir que chaque règle dans un pare-feu a toujours le besoin d’exister ?

2. Qu’est-ce qu’un outil de gestion et d’orchestration des politiques de sécurité réseau ?

Si cet outil n’est pas encore déployé dans votre système d’information, il y a de grande chance que le cycle de vie de vos règles et donc la gestion de vos politiques de sécurité soient défaillantes.

2.1 Le cycle de vie d’une règle de sécurité

Par nature, les pare-feu bloquent l’intégralité des canaux de communication et seul la mise en place une règle de sécurité donne l’accès/expose une ressource ou un service pendant un durée plus ou moins longue. De manière générale, une équipe de sécurité réseau opérationnelle code la règle sur un ou plusieurs pare-feu directement en GUI, en CLI ou au travers d’une console de management centrale en fonction des éditeurs de solutions qui ont été retenues pour protéger votre système d’information.

Au regard de la roue de deming et de sa méthode de gestion de la qualité dite PDCA (Plan, Do, Check, Act), les équipes de sécurité réseau opérationnelle n’arrive toujours à leur fin pour ouvrir des canaux de communication pour que l’application X fonctionne pour Y utilisateurs, mais à quel prix ?

2.1.1 PLAN – Phase d’observation et de compréhension

La segmentation du système d’information est une facteur de déterminant pour atteindre votre enjeu de défense du patrimoine informatique. De nos jours, l’actualité tourne autour du modèle d’architecture Zero Trust, si votre réseau n’était pas un déjà un casse-tête pour vos équipes opérationnelles, il le deviendra avec ce modèle sans les outils suffisants pour vous permettre d’atteindre ce modèle et bénéficier des gains qui en découlent.

L’enjeu de cette phase est de démystifier la complexité de votre réseau pour répondre à la question : Sur quel pare-feu doit-on implémenter des règles pour répondre à la demande?

2.2.2 DO – Phase d’implémentation

De nos jours, les applications sont de plus en plus tournées vers l’externe du système d’information est nécessite donc plus de réactivité, car les opérations qui ne concernaient en grande majorité que les équipes d’infrastructure rencontrent aujourd’hui les équipes DEVOPS, les équipes outils, les équipements de développement et les gestionnaires d’applications, sans compter sur le volume de demande qui explose le backlog.

2.2.3 Check – Phase de Vérification

Être un administrateur de pare-feu ne s’improvise pas, cela requière des compétences fortes en réseau et sécurité, des différents protocoles et services les plus communs utilisés (sécurisés et non), en architecture (3tiers notamment) etc…

Les demandeurs sont à la merci des équipes qui œuvrent pour ouvrir les canaux de communication dans les pare-feu. Alors que ces équipes devraient être vu comme de vrais héros des temps digitaux et la sécurité défensive qu’ils apportent comme un vrai gage de qualité, le manque d’outils, de compétences ou de formation et de temps sont souvent des facteurs qui jouent contre eux.

Qui contrôle que les implémentations qui ont été faite correspondent parfaitement à la demande initiale ?

Quand une règle a été créée et pourquoi ?

Combien de temps la règle est conservée dans le ou les pare-feu ?

Qui est le propriétaire d’une règle dans un pare-feu ?

Qui conserve l’ensemble des règles d’une application ?

2.2.4 ACT – Phase de contrôle

Dans une organisation classique, on retrouve des équipes qui assurent les tâches opérationnelles et un contrôle de niveau 1 appelé « contrôle continu » puis une équipe de sécurité globale qui assurent un contrôle de niveau 2 appelé « contrôle permanent ». Trop souvent, ces équipes ne sont pas outillées pour atteindre leurs objectifs et répondre aux questions ci-dessous de manière totalement claire et sereine sans déployer une armada et de processus qui ferait défaut au besoin de rapidité.

Il existe sur le marché plusieurs outils de gestion et d’orchestration des politiques de sécurité réseau, chacun, avec une vision qui leur est propre. Les acteurs majeurs sur le marché sont Tufin et Algosec, derrière on retrouve Firemon et Skybox.

2.2 Quelles sont les fonctionnalités attendues d’un outil de gestion et d’orchestration des politiques de sécurité ?

Tout est dans le nom. La Gestion correspond au cycle de vie de chacune des règle des politiques de sécurité déployées sur chaque pare-feu du système d’information, notamment sur la phase de contrôle (2.2.4). L’Orchestration correspond quand à elle aux phases de compréhension, d’implémentation ET de vérification.

Les acteurs majeurs du marché proposent le même découpage applicatifs pour répondre à cette ambition:

Le moteur : Cœur de la solution qui digère l’ensemble des configurations des équipements de niveau 3 afin de modéliser une cartographie réseau du système d’information. On retrouve comme équipements de routage ou de niveau 3 :
- Les pare-feu
- Les routeurs
- Les switchs de niveau 3
- Les load balancers
- Les proxy
- les clouds
- Les infrastructure de virtualisation
Le workflow : Modélisation du processus d’ouverture de flux afin de le rendre le plus automatique possible.