Revue des règles de pare-feu pour ISO 27001, NIS2, DORA et GDPR
Il est 07 h 42 un lundi matin. Le RSSI d’un fournisseur SaaS et FinTech en forte croissance consulte trois messages distincts.
Le premier vient du SOC. Un poste de travail de développeur compromis a tenté, pendant la nuit, de se connecter à un sous-réseau interne de bases de données. Le trafic a été bloqué, mais l’analyste souhaite confirmer que la règle de pare-feu est intentionnelle, à jour et approuvée.
Le deuxième vient d’un grand compte. Il demande des éléments probants démontrant que les environnements de production, de développement, bureautiques et de support sont segmentés, que les règles de pare-feu sont revues et que les exceptions expirent effectivement.
Le troisième vient du responsable de la conformité. L’organisation est exposée à NIS2 en tant que fournisseur numérique important, assume des responsabilités au titre du GDPR en tant que sous-traitant et compte des clients du secteur financier qui demandent des éléments probants de gestion des risques liés aux TIC dans l’esprit de DORA. Le conseil d’administration veut savoir si les mêmes éléments probants ISO/IEC 27001:2022 peuvent répondre aux trois attentes.
Puis arrive la revue post-incident. Un serveur de développement a failli être exposé à Internet lors d’un changement effectué tard dans la nuit. Aucune donnée client n’a été perdue, mais l’équipe d’investigation numérique a découvert un problème plus grave que l’erreur initiale : une règle de pare-feu de « test temporaire », vieille de cinq ans, autorisait encore des déplacements latéraux étendus entre le développement et la production. Si un attaquant avait obtenu un accès, le réseau aurait opposé peu de résistance.
C’est souvent à ce moment que les organisations découvrent une réalité difficile. Elles disposent parfois de pare-feu, de VLAN, de groupes de sécurité cloud et de schémas, mais elles n’ont pas de gouvernance sur les zones de segmentation, la propriété des règles, les accès temporaires, les approbations de changements, la recertification et les éléments probants d’audit.
En 2026, « nous avons un pare-feu » n’est pas une réponse défendable. Les auditeurs, les autorités de régulation, les clients et les assureurs veulent la preuve que les réseaux sont séparés de manière intentionnelle, que le trafic est contrôlé selon le besoin métier, que les exceptions à risque sont encadrées et que les journaux démontrent le fonctionnement effectif des contrôles.
Pourquoi la gouvernance des pare-feu est désormais un sujet de niveau conseil d’administration
La segmentation réseau était historiquement traitée comme un sujet d’ingénierie technique. Les équipes d’infrastructure détenaient les VLAN, les administrateurs de pare-feu maintenaient les bases de règles, les équipes cloud géraient les groupes de sécurité, et la conformité ne voyait qu’un schéma pendant les audits.
Ce modèle opérationnel ne fonctionne plus.
La directive NIS2 impose aux entités essentielles et importantes de mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées afin de gérer les risques pesant sur les réseaux et les systèmes d’information. L’Article 21 couvre notamment les politiques d’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la sécurité lors de l’acquisition et de la maintenance, l’évaluation de l’efficacité, l’hygiène cyber de base, le contrôle d’accès et la gestion des actifs. Les organes de direction doivent approuver et superviser ces mesures de gestion des risques de cybersécurité.
DORA s’applique à partir du 17 janvier 2025 à de nombreuses entités financières et fait de la gestion des risques liés aux TIC une discipline gouvernée et documentée. Les Articles 5, 6 et 8 exigent une gouvernance, un cadre de gestion des risques liés aux TIC, ainsi que l’identification des fonctions métier soutenues par les TIC, des actifs informationnels, des actifs TIC, des dépendances, des actifs critiques et des interconnexions. Les Articles 9, 10 et 11 portent sur la protection, la prévention, la détection, la réponse et le rétablissement. Les Articles 24 à 27 imposent des tests de résilience opérationnelle numérique, y compris des tests avancés pour certaines entités. La segmentation devient donc un sujet de résilience, et pas seulement un sujet de pare-feu.
Le GDPR ajoute la couche de responsabilité en matière de protection des données. L’Article 32 impose des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque, incluant la confidentialité, l’intégrité, la disponibilité et la résilience. L’Article 5(1)(f) exige l’intégrité et la confidentialité, et l’Article 5(2) impose la responsabilité. Si des systèmes traitant des données à caractère personnel sont joignables depuis des terminaux compromis, des réseaux Wi‑Fi invités ou des chemins tiers non maîtrisés, une autorité de contrôle peut demander pourquoi ces chemins existaient.
ISO/IEC 27001:2022 fournit le socle de système de management qui relie ces obligations. La norme exige un périmètre, les exigences des parties intéressées, l’appréciation des risques, le traitement des risques, une Déclaration d’applicabilité, la planification et la maîtrise opérationnelles, la responsabilité de la direction, des objectifs mesurables, des informations documentées et l’amélioration continue. L’Annexe A, appuyée par les lignes directrices ISO/IEC 27002:2022, comprend les domaines de contrôle nécessaires pour le risque fournisseur, les services cloud, la journalisation, la surveillance, l’architecture sécurisée, la séparation des environnements et la gestion des changements.
Le point clé est simple : la segmentation réseau et la revue des règles de pare-feu sont désormais des éléments probants de gouvernance.
Le modèle opérationnel Clarysec : 8.20, 8.22 et 8.32
Clarysec traite la segmentation et la revue des pare-feu comme un même modèle opérationnel couvrant plusieurs contrôles ISO/IEC 27002:2022, et non comme des tâches techniques isolées.
Les trois contrôles principaux sont les suivants :
| Domaine ISO/IEC 27002:2022 | Question de gouvernance | Éléments probants attendus par les auditeurs |
|---|---|---|
| 8.20 Sécurité des réseaux | Les réseaux sont-ils conçus, administrés, surveillés et protégés en fonction du risque ? | Schémas d’architecture, standards de pare-feu, procédures réseau sécurisées, journaux de surveillance, éléments probants IDS/IPS, échantillons de configurations VPN et de réseau cloud |
| 8.22 Séparation des réseaux | Les zones sont-elles séparées selon la sensibilité, la fonction et le niveau de confiance ? | Modèle de zonage, matrice des flux de données, conception des VLAN et sous-réseaux, frontières DMZ, règles de pare-feu interzones, résultats des tests de segmentation |
| 8.32 Gestion des changements | Les changements de règles sont-ils évalués, approuvés, testés, journalisés et revus ? | Tickets de changement, appréciations des risques, approbations, plans de retour arrière, revues après mise en œuvre, enregistrements de changements d’urgence |
Dans Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], Clarysec place la sécurité réseau dans la phase Contrôles en action, étape 20 : contrôles 8.18 à 8.26. Le guide formule clairement la question centrale d’audit :
« Au fond, ce contrôle impose aux organisations de veiller à ce que les réseaux soient sécurisés par leur architecture, et non simplement par l’ajout ultérieur de pare-feu ou d’antivirus. Cela implique de réfléchir de manière stratégique à la segmentation réseau, au contrôle d’accès, au chiffrement en transit, à la surveillance et à la défense en profondeur. Le point de départ est une question simple : qui et quoi communiquent, et cette communication doit-elle exister ? »
Cette question, « qui et quoi communiquent, et cette communication doit-elle exister ? », est le meilleur point de départ opérationnel pour la revue des règles de pare-feu. Elle déplace la discussion de milliers d’entrées ACL cryptiques vers des flux justifiés par le métier.
Le même Zenith Blueprint demande aux équipes d’évaluer l’architecture réseau en vérifiant que les règles de pare-feu, IPS/IDS et configurations d’accès à distance sont à jour et durcies, et de confirmer que les groupes de sécurité cloud, le routage et les règles VPC ou de sous-réseau correspondent à l’architecture prévue. Il indique également aux auditeurs d’attendre un schéma d’architecture de sécurité réseau montrant les pare-feu, les passerelles VPN, les zones DMZ, la séparation VLAN et les frontières de confiance.
Pour la gestion des changements, le Zenith Blueprint place le contrôle ISO/IEC 27002:2022 8.32 dans la phase Contrôles en action, étape 21 : contrôles 8.27 à 8.34, et souligne pourquoi la gouvernance des pare-feu échoue lorsque la maîtrise des changements est faible :
« Ce contrôle reconnaît une vérité difficile en informatique : de nombreux incidents ne sont pas causés par des attaques, mais par des changements mal maîtrisés. Une règle de pare-feu ouverte trop largement. Un paramètre de débogage laissé activé. Une dépendance oubliée après une migration. »
C’est exactement ainsi que des ouvertures temporaires de pare-feu deviennent des chemins d’attaque permanents.
À quoi ressemble une bonne segmentation réseau
Un programme de segmentation mature comporte quatre couches.
Premièrement, il dispose d’un modèle de zonage. Les zones ne sont pas des sous-réseaux arbitraires. Ce sont des frontières de confiance alignées sur la fonction métier et la sensibilité des données, par exemple une DMZ exposée à Internet, une couche applicative de production, une couche de bases de données de production, un réseau d’utilisateurs d’entreprise, un réseau d’administration à privilèges, un environnement de développement, un environnement de test, un réseau de sauvegarde, un Wi‑Fi invité, une zone OT ou IoT et une zone d’accès des tiers.
Deuxièmement, il dispose d’une matrice des flux. Pour chaque paire de zones, l’organisation documente la source autorisée, la destination, le protocole, le port, l’application, le responsable métier, le propriétaire du système, le type de données, la justification et l’exigence de journalisation.
Troisièmement, il définit la propriété des règles. Chaque règle de pare-feu, règle de groupe de sécurité cloud ou politique de périmètre défini par logiciel a un propriétaire, une date d’expiration ou de recertification, un ticket de changement lié et une justification métier. Les règles « any to any » doivent être traitées comme un constat, sauf si le risque a été formellement accepté pour une durée limitée et si elles sont appuyées par des contrôles compensatoires.
Quatrièmement, il prévoit une revue récurrente. La revue ne consiste pas seulement à exporter une base de règles de pare-feu une fois par an. Elle comprend la recertification par les propriétaires, la comparaison avec le trafic observé, la détection des règles inutilisées, la validation des exceptions temporaires, la revue de l’exposition Internet, les tests de segmentation et le rapprochement avec l’inventaire des actifs.
La Network Security Policy [P-NS] de Clarysec fixe clairement l’exigence applicable à l’entreprise :
« Tout trafic interzone doit être contrôlé par des pare-feu ou des solutions de périmètre défini par logiciel, avec des configurations explicites de refus par défaut. »
Extrait de la politique d’entreprise, Network Security Policy, section « Exigences de gouvernance », clause 5.2.
La même politique relie directement les changements de pare-feu à la gestion des changements :
« Toute modification des bases de règles de pare-feu, des tables de routage ou des configurations de groupes de sécurité doit suivre la politique de gestion des changements (P5) de l’organisation, y compris les plans de retour arrière et la journalisation d’audit. »
Extrait de la politique d’entreprise, Network Security Policy, section « Exigences de gouvernance », clause 5.4.
Pour les PME, la Network Security Policy-sme [P-NS-SME] de Clarysec reprend le même principe en termes opérationnels :
« Des règles de refus par défaut doivent être appliquées pour toutes les connexions entrantes, sauf lorsqu’elles sont explicitement requises et approuvées »
Extrait de la politique PME, Network Security Policy-sme, section « Exigences de mise en œuvre de la politique », clause 6.1.2.
Et, spécifiquement pour la segmentation :
« Le trafic entre segments doit être filtré, et l’accès intersegment doit respecter le principe du moindre privilège »
Extrait de la politique PME, Network Security Policy-sme, section « Exigences de mise en œuvre de la politique », clause 6.2.3.
Ces clauses de politique permettent à un auditeur de remonter du risque au contrôle, du contrôle à la règle, de la règle à l’approbation, puis de l’approbation aux journaux.
Un dossier unique d’éléments probants pour ISO 27001, NIS2, DORA et GDPR
L’erreur fréquente consiste à constituer des dossiers d’éléments probants séparés : un pour ISO/IEC 27001:2022, un pour NIS2, un pour GDPR, un pour les clients DORA et un pour la cyberassurance.
Une meilleure approche consiste à constituer un dossier unique d’éléments probants sur la segmentation et la gouvernance des pare-feu, mis en correspondance avec plusieurs référentiels.
Zenith Controls: The Cross-Compliance Guide [ZC] associe le contrôle ISO/IEC 27002:2022 8.22 Séparation des réseaux à un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur la fonction de cybersécurité Protect et sur la capacité opérationnelle de sécurité des systèmes et des réseaux. Le guide relie 8.22 à 8.20 Sécurité des réseaux, 8.21 Sécurité des services réseau, 8.7 Protection contre les logiciels malveillants, 8.27 Principes d’architecture et d’ingénierie des systèmes sécurisés et 8.31 Séparation des environnements de développement, de test et de production.
Le guide explique ainsi la pertinence de la segmentation pour NIS2 :
« La séparation des réseaux répond directement à ces obligations, en réduisant les surfaces d’attaque et en empêchant les mouvements latéraux dans les systèmes interconnectés. »
Cette phrase explique pourquoi les programmes d’hygiène cyber NIS2 ne doivent pas traiter la segmentation comme facultative. Le confinement des rançongiciels ne repose pas uniquement sur la protection des terminaux. Il consiste aussi à limiter les mouvements latéraux lorsque la prévention échoue.
Pour GDPR, Zenith Controls met 8.22 en correspondance avec l’Article 32 et le considérant 49, en précisant que les schémas réseau et les politiques de zonage deviennent des éléments probants clés de conformité. Pour DORA, Zenith Controls relie la sécurité réseau et la séparation des réseaux à la gestion des risques liés aux TIC et au confinement des incidents. Les tests de segmentation peuvent soutenir les éléments probants de résilience TIC, en particulier lorsqu’ils démontrent qu’une compromission dans une zone ne peut pas se déplacer librement vers des services financiers critiques, des référentiels de données à caractère personnel ou des systèmes d’administration à privilèges.
| Livrable d’audit | Utilisation ISO/IEC 27001:2022 et ISO/IEC 27002:2022 | Utilisation NIS2 | Utilisation DORA | Utilisation GDPR |
|---|---|---|---|---|
| Schéma d’architecture de sécurité réseau | Soutient le périmètre du SMSI, la maîtrise opérationnelle, 8.20 et 8.22 | Montre les mesures techniques de sécurité des réseaux et des systèmes d’information | Montre les interconnexions TIC et les dépendances des services critiques | Montre les frontières de protection autour des systèmes traitant des données à caractère personnel |
| Matrice des zones et des flux | Démontre la séparation fondée sur les risques et le moindre privilège | Soutient l’hygiène cyber et l’évaluation de l’efficacité | Soutient la classification des actifs TIC et des dépendances | Soutient les mesures techniques et la responsabilité prévues par l’Article 32 |
| Enregistrements de revue des règles de pare-feu | Éléments probants de surveillance des contrôles et d’amélioration continue | Montre que les mesures sont revues et ne restent pas statiques | Soutient la revue du risque TIC et les tests de résilience | Démontre la sécurité continue du traitement |
| Tickets de changement pour les règles de pare-feu | Soutiennent la gestion des changements 8.32 | Soutiennent la maintenance sécurisée et la traçabilité | Soutiennent les changements TIC maîtrisés et la résilience | Montrent que les changements affectant les systèmes traitant des données à caractère personnel font l’objet d’une appréciation des risques |
| Registre des exceptions | Soutient le traitement des risques et l’acceptation du risque résiduel | Montre la supervision des écarts par la direction | Soutient la tolérance au risque et la gouvernance | Montre la responsabilité relative aux expositions temporaires |
| Journaux de trafic interzone bloqué et autorisé | Soutiennent la journalisation, la surveillance et l’efficacité des contrôles | Soutiennent la détection et la réponse aux incidents | Soutiennent la catégorisation et le signalement des incidents | Soutiennent l’évaluation des violations et la conservation des éléments de preuve |
Ce tableau n’est pas seulement une correspondance de conformité. C’est une feuille de route pour la collecte des éléments probants.
La revue des règles de pare-feu qui fonctionne réellement
Une revue des règles de pare-feu échoue lorsqu’elle se limite à demander : « cette règle est-elle encore nécessaire ? ». Les propriétaires de règles répondent souvent oui parce qu’ils craignent de provoquer une interruption.
Une meilleure revue pose six questions :
- Quel service métier cette règle soutient-elle ?
- Quel propriétaire de l’actif et quel propriétaire des données ont approuvé le flux ?
- La destination se trouve-t-elle dans la zone appropriée au regard des données et de la fonction ?
- La règle est-elle plus permissive que ne l’exige le trafic observé ?
- La journalisation est-elle activée pour les flux à haut risque ?
- La règle dispose-t-elle d’une date de revue, d’une date d’expiration ou d’un enregistrement d’exception ?
La Network Security Policy-sme exige une revue périodique :
« Le prestataire de support informatique doit réaliser une revue annuelle des règles de pare-feu, de l’architecture réseau et des configurations sans fil »
Extrait de la politique PME, Network Security Policy-sme, section « Exigences de gouvernance », clause 5.6.1.
La revue annuelle est le socle, pas le plafond. Les règles à haut risque nécessitent une recertification plus fréquente.
| Catégorie de règle | Exemple | Fréquence de revue | Exigence d’approbation |
|---|---|---|---|
| Trafic entrant Internet vers la production | API publique vers passerelle applicative | Trimestrielle ou après une mise en production majeure | Responsable de service, sécurité, approbateur du changement |
| Accès interzone à une base de données de production | Couche applicative vers couche base de données | Trimestrielle | Propriétaire d’application et propriétaire des données |
| Accès administratif | Bastion d’administration vers ports d’administration serveur | Mensuelle ou trimestrielle | Propriétaire de l’infrastructure et délégué du RSSI |
| Accès des tiers | VPN fournisseur vers sous-réseau de support | Mensuelle ou jalon contractuel | Responsable fournisseur et sécurité |
| Exception temporaire | Accès d’urgence pendant une migration | Avant expiration, maximum 90 jours | Responsable du SMSI ou RSSI |
| Règle interne standard à faible risque | Serveur de supervision vers terminaux administrés | Annuelle | Responsable de service |
La Network Security Policy est explicite sur les exceptions :
« La demande doit être revue et approuvée par le responsable du SMSI ou le RSSI et consignée dans le registre des dérogations du SMSI, avec une période d’approbation maximale de 90 jours, renouvelable après réévaluation. »
Extrait de la politique d’entreprise, Network Security Policy, section « Traitement des risques et exceptions », clause 7.3.
Pour les PME, la Network Security Policy-sme impose que les demandes d’exception contiennent les informations minimales appropriées :
« La demande doit inclure la justification, le périmètre, la durée et les contrôles compensatoires (par exemple, liste d’autorisation IP, journalisation) »
Extrait de la politique PME, Network Security Policy-sme, section « Traitement des risques et exceptions », clause 7.3.3.
Cette clause transforme la gestion des exceptions, qui peut sinon rester une conversation informelle, en traitement des risques vérifiable en audit.
Exemple pratique : supprimer une règle risquée d’accès à une base de données de production
Supposons qu’une entreprise identifie la règle suivante lors de la revue :
| Champ | Valeur actuelle |
|---|---|
| Source | VLAN des utilisateurs d’entreprise |
| Destination | Sous-réseau de bases de données de production |
| Port | TCP 5432 |
| Action | Autoriser |
| Commentaire | Accès temporaire pour migration du reporting |
| Créée | Il y a 14 mois |
| Propriétaire | Inconnu |
| Journalisation | Désactivée |
Il s’agit d’un constat d’audit classique. La règle viole le principe du moindre privilège, n’a pas de propriétaire clair, pas d’expiration, pas de justification actuelle et pas de journalisation. Elle crée également une exposition au titre de l’Article 32 du GDPR si la base de données de production contient des données à caractère personnel de clients.
Le processus de remédiation doit créer des éléments probants, et pas seulement supprimer une mauvaise règle.
| Étape | Action | Référence Clarysec | Élément probant d’audit créé |
|---|---|---|---|
| 1. Mettre la règle en correspondance avec le modèle de zones | Confirmer si les utilisateurs d’entreprise doivent un jour atteindre le sous-réseau de bases de données de production | Zenith Blueprint, Contrôles en action, étape 20 | Notes de revue d’architecture mises à jour et classification de zone |
| 2. Créer ou mettre à jour l’enregistrement de flux | Documenter la source, la destination, le port, le type de données, le propriétaire, la justification et le risque | Zenith Controls, correspondance 8.22 | Entrée dans la matrice des zones et des flux |
| 3. Ouvrir un ticket de changement | Proposer la suppression ou le remplacement par un chemin maîtrisé de service de reporting | Network Security Policy, clause 5.4 | Enregistrement de changement avec analyse des risques, plan de test et plan de retour arrière |
| 4. Décider du traitement | Supprimer la règle trop large ou la remplacer par un réplica en lecture seule, un bastion, une liste d’autorisation IP et de la journalisation | Network Security Policy, clause 7.3 | Décision de traitement des risques ou exception limitée dans le temps |
| 5. Activer la journalisation pour les flux approuvés | Envoyer les événements de pare-feu interzones à haut risque vers la supervision | Logging and Monitoring Policy, clause 6.1.1.6 | Enregistrements SIEM, règles d’alerte et captures d’écran de supervision |
| 6. Valider la segmentation | Tester que le sous-réseau de bases de données est inaccessible sauf par les chemins approuvés | Zenith Blueprint, étape 20 | Résultat de test de segmentation et clôture de la remédiation |
La Logging and Monitoring Policy [P-LM] de Clarysec inclut les communications externes et les déclencheurs de règles de pare-feu parmi les événements pertinents pour les journaux :
« Communications externes et déclencheurs de règles de pare-feu »
Extrait de la politique d’entreprise, Logging and Monitoring Policy, section « Exigences de mise en œuvre de la politique », clause 6.1.1.6.
Pour les règles interzones à haut risque, les déclencheurs de pare-feu doivent alimenter le SIEM ou la plateforme de supervision, avec des alertes sur les hôtes sources, volumes ou fenêtres temporelles inhabituels.
La politique PME impose également une discipline de changement :
« Tous les changements apportés aux configurations réseau (règles de pare-feu, ACL de commutateurs, tables de routage) doivent suivre un processus documenté de gestion des changements »
Extrait de la politique PME, Network Security Policy-sme, section « Exigences de mise en œuvre de la politique », clause 6.9.1.
Une seule opération de nettoyage de cette règle produit des éléments probants pour la maîtrise opérationnelle ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 et 8.32, l’hygiène cyber NIS2, l’Article 32 du GDPR et la gestion des risques liés aux TIC de type DORA.
Les réseaux cloud, SaaS et hybrides doivent être inclus
La segmentation moderne ne se limite pas aux VLAN et aux pare-feu physiques. Elle inclut les groupes de sécurité AWS, les groupes de sécurité réseau Azure, les politiques réseau Kubernetes, les tables de routage cloud, les listes d’autorisation d’administration SaaS, les points de terminaison privés, les VPN, le SD-WAN, les proxys sensibles à l’identité et les contrôles de périmètre défini par logiciel.
Pour un fournisseur SaaS ou un service numérique réglementé, la revue des règles de pare-feu doit couvrir au minimum :
- Répartiteurs de charge et passerelles applicatives exposés à Internet
- Groupes de sécurité cloud et ACL réseau
- Tables de routage de sous-réseaux privés
- Chemins de peering et de passerelle de transit
- VPN et chemins d’administration à distance
- Interfaces d’administration et plans de gestion
- Ingress Kubernetes et politiques réseau
- Accès des runners CI/CD à l’environnement de production
- Couverture de journalisation des flux à haut risque refusés et autorisés
- Accès de support des tiers et chemins d’accès d’urgence
Si un groupe de sécurité cloud autorise le trafic entrant vers une base de données depuis une plage IP d’entreprise trop large, il doit être traité comme une règle de pare-feu. Il lui faut un propriétaire, une justification, une approbation, une revue, une journalisation et une expiration.
C’est également là que les normes ISO complémentaires renforcent l’argumentaire. ISO/IEC 27017 clarifie les responsabilités de sécurité cloud. ISO/IEC 27033 fournit des lignes directrices plus approfondies sur l’architecture de sécurité réseau, les DMZ, les zones de segmentation, le filtrage du trafic et les communications interréseaux sécurisées. ISO/IEC 27701 renforce la gouvernance de la protection des données lorsque des informations personnellement identifiables (PII) circulent entre réseaux. ISO/IEC 27035 soutient le confinement des incidents, et ISO/IEC 27005 soutient le choix de la segmentation comme traitement des risques contre l’accès non autorisé, la propagation de logiciels malveillants et les mouvements latéraux.
Comment les auditeurs testent différemment le même contrôle
L’une des forces de Zenith Controls est d’expliquer comment différentes méthodologies d’audit examinent le même contrôle. Les éléments probants peuvent être réutilisés, mais les questions diffèrent.
| Angle d’audit | Question probable | Meilleurs éléments probants |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 | La segmentation est-elle sélectionnée, mise en œuvre et revue en fonction du risque ? | Appréciation des risques, SoA, politique réseau, schémas, enregistrements de revue |
| Auditeur de type ISO/IEC 27007 | Les règles de pare-feu mises en œuvre et les schémas VLAN correspondent-ils à la politique documentée ? | Échantillons de règles de pare-feu, ACL de routeurs, conception VLAN, entretiens avec les administrateurs |
| Approche d’audit de certification ISO/IEC 27006-1:2024 | Les frontières réseau critiques sont-elles auditées avec une compétence appropriée et une planification fondée sur les risques ? | Plan d’audit, échantillonnage technique, éléments probants de groupes de sécurité cloud, résultats de tests |
| Auditeur orienté NIST | Les frontières et les flux d’information sont-ils appliqués et surveillés ? | Règles de pare-feu, ACL, tests de segmentation, enregistrements de supervision |
| Auditeur COBIT 2019 | La sécurité réseau est-elle gouvernée, surveillée et reportée à la direction ? | Matrice de propriété, KPI, rapports à la direction, registre des risques |
| Auditeur ISACA ITAF | Les contrôles généraux informatiques fonctionnent-ils de manière cohérente ? | Tickets de changement, approbations d’exceptions, journaux, échantillons de recertification des règles |
| Autorité de contrôle GDPR | Les systèmes traitant des données à caractère personnel étaient-ils protégés par des mesures techniques appropriées ? | Cartographies des flux de données, isolement des zones PII, chemins d’accès, journaux de pare-feu |
| Évaluateur orienté DORA | La segmentation soutient-elle la résilience TIC et le confinement des incidents ? | Cartographie des dépendances des actifs TIC, flux des fonctions critiques, playbooks d’incident, enregistrements de tests |
Un évaluateur orienté DORA peut demander si une compromission d’une passerelle de paiement peut pivoter vers des bases de données clients. Une autorité compétente NIS2 peut demander si un rançongiciel sur un poste d’administration peut atteindre les systèmes principaux de fourniture du service. Une autorité GDPR peut demander quelles restrictions au niveau réseau protégeaient les systèmes traitant des données à caractère personnel. Un auditeur ISO peut simplement demander l’appréciation des risques, la SoA, la politique, la procédure et les éléments probants montrant que les revues ont eu lieu.
Les meilleurs programmes répondent à toutes ces questions avec les mêmes livrables d’audit.
Des indicateurs qui rendent la segmentation visible pour la direction
NIS2 et DORA renforcent tous deux la responsabilité de la direction. ISO/IEC 27001:2022 exige le leadership, les objectifs, les rôles, les ressources, le reporting et l’amélioration continue. La segmentation doit donc disposer d’indicateurs compréhensibles par la direction.
Les indicateurs utiles pour la direction incluent :
- Pourcentage de règles de pare-feu ayant un propriétaire désigné
- Pourcentage de règles ayant une justification métier documentée
- Nombre de règles temporaires expirées
- Nombre de règles avec source, destination ou service « any »
- Nombre de services exposés à Internet par criticité
- Pourcentage de flux interzones à haut risque avec journalisation activée
- Nombre de changements de pare-feu d’urgence par trimestre
- Pourcentage de règles échantillonnées rattachées à des tickets de changement approuvés
- Nombre d’échecs aux tests de segmentation
- Délai moyen de remédiation des règles risquées ou inutilisées
- Nombre d’exceptions de plus de 90 jours
- Nombre de règles d’accès des tiers revues et recertifiées
La Network Security Policy identifie « l’efficacité des règles de pare-feu » comme un point de conformité et d’application dans la section « Application et conformité », clause 8.2.2. Cette formulation est importante, car l’existence des règles ne suffit pas. Les règles doivent être efficaces, revues et alignées sur le risque actuel.
Constituer le dossier d’éléments probants de segmentation 2026
Un dossier pratique d’éléments probants sur la segmentation et la revue des règles de pare-feu doit être prêt avant que l’auditeur ne le demande.
Au minimum, maintenez :
- Un schéma d’architecture réseau à jour, incluant les zones cloud et hybrides
- Un standard de classification des zones, incluant la sensibilité et le niveau de confiance
- Une matrice des flux pour les services critiques et les systèmes traitant des données à caractère personnel
- Un export des règles de pare-feu et de groupes de sécurité cloud
- Un registre des propriétaires de règles et de recertification
- Une procédure de revue des pare-feu et un calendrier de revue
- Des enregistrements de changement pour les modifications de pare-feu échantillonnées
- Un registre des exceptions avec approbations, expiration et contrôles compensatoires
- Des résultats de tests de segmentation et des enregistrements de remédiation
- Des éléments probants de journalisation et de supervision pour les flux à haut risque
- Des playbooks d’incident montrant le confinement par zone
- Des indicateurs de reporting à la direction et des comptes rendus de réunion
Mettez ces éléments probants en correspondance avec les clauses ISO/IEC 27001:2022 et les domaines de contrôle de l’Annexe A. Référencez-les ensuite avec l’Article 21 de NIS2, l’Article 32 du GDPR, les exigences de gestion des risques liés aux TIC et de tests DORA, les résultats NIST CSF 2.0 tels que GOVERN, PROTECT, DETECT et RESPOND, ainsi que les pratiques de gouvernance COBIT.
NIST CSF 2.0 est particulièrement utile comme couche de communication avec le conseil d’administration. Sa fonction GOVERN porte sur les exigences légales, réglementaires et contractuelles, l’appétence au risque, les rôles, les politiques et la supervision. Ses résultats opérationnels couvrent la gestion des configurations, la journalisation, la surveillance, la protection des données, la réponse aux incidents et le rétablissement. Cela aide la direction à comprendre le risque sans lire les ACL de pare-feu.
Constats fréquents observés par Clarysec dans les audits de segmentation
Dans les environnements SaaS, fintech, chez les prestataires de services managés et dans les PME réglementées, les mêmes constats reviennent régulièrement :
- Réseau plat entre les terminaux utilisateurs et les services de production
- Bases de données de production joignables depuis les réseaux de développement ou d’entreprise
- Groupes de sécurité cloud trop larges copiés depuis d’anciens modèles
- Règles temporaires fournisseurs sans expiration
- Changements de pare-feu réalisés hors processus de changement
- Règles sans propriétaire ni justification métier
- Journalisation désactivée sur des règles d’autorisation à haut risque
- Wi‑Fi invité insuffisamment isolé
- Interfaces d’administration joignables depuis les réseaux généraux
- Schémas ne correspondant pas au routage réel
- Absence d’éléments probants montrant que les revues de règles ont été réalisées
- Absence de tests de segmentation après des changements majeurs d’architecture
- Absence de correspondance entre les systèmes traitant des données à caractère personnel et les zones réseau
- Absence de reporting à la direction sur l’exposition réseau
Ces constats ne sont pas seulement des faiblesses techniques. Ils compromettent la capacité de l’organisation à prouver son hygiène cyber NIS2, sa résilience opérationnelle DORA et sa responsabilité au titre de l’Article 32 du GDPR.
Du nettoyage réactif au contrôle défendable
La segmentation réseau et la revue des règles de pare-feu sont le point de rencontre entre l’architecture de sécurité et la réalité de l’audit. Si vous pouvez présenter un modèle de zonage fondé sur les risques, des flux interzones maîtrisés, des changements de pare-feu approuvés, des exceptions limitées dans le temps, des éléments probants de journalisation et une validation périodique, vous pouvez répondre à un large éventail de questions ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST et COBIT avec un récit cohérent.
Clarysec peut vous aider à construire ce récit.
Utilisez Zenith Blueprint: An Auditor’s 30-Step Roadmap pour structurer le parcours de mise en œuvre, en particulier la phase Contrôles en action, étape 20, pour la sécurité réseau et la segmentation, et l’étape 21 pour la gestion des changements. Utilisez Zenith Controls: The Cross-Compliance Guide pour mettre en correspondance les contrôles ISO/IEC 27002:2022 8.20, 8.22 et 8.32 avec les attentes d’audit NIS2, DORA, GDPR, NIST et COBIT. Ancrez vos règles opérationnelles dans les politiques Clarysec Network Security Policy, Network Security Policy-sme et Logging and Monitoring Policy.
Votre prochaine étape est simple et à forte valeur : sélectionnez un service critique, par exemple la production client, le traitement des paiements ou la gestion des identités, et réalisez cette semaine une revue par échantillon de 10 règles. Pour chaque règle, confirmez le propriétaire, la justification, la source, la destination, le port, la journalisation, le ticket de changement et l’expiration. Si vous ne pouvez pas prouver ces sept éléments, vous tenez le point de départ de votre plan d’amélioration de la segmentation 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
