Si vous utilisez la segmentation pour garder une partie de votre parc hors périmètre, le standard vous demande de prouver, par un test, que la segmentation fonctionne. Si la preuve est faible, le périmètre n’est pas prouvé, et tout ce qui est évalué à l’intérieur non plus. Voici ce que le test doit faire.
Ce que l’exigence demande
L’exigence 11.4.5 demande un test d’intrusion des contrôles de segmentation au moins une fois tous les douze mois, et après tout changement de ces contrôles, confirmant qu’ils sont opérationnels et efficaces et qu’ils isolent chaque réseau hors périmètre de l’environnement des données de cartes. Les prestataires de services le font au moins tous les six mois au titre de la 11.4.6. Le test doit suivre une méthodologie définie, couvrir toutes les méthodes de segmentation utilisées, et être réalisé par un testeur qualifié, indépendant sur le plan organisationnel des personnes qui gèrent les contrôles.
Depuis où
Depuis chaque réseau hors périmètre. Pas depuis une seule machine de rebond sur un réseau que le rapport ne nomme pas. Si vous avez un réseau bureautique, un réseau de développement, un réseau partenaire, trois réseaux cloud appairés et le réseau d’administration d’un fournisseur, vous avez au moins sept réseaux sources, et le rapport devrait les lister. Le test depuis un point prouve l’isolation depuis un point.
Le test depuis un point prouve l’isolation depuis un point.
Vers quoi
Vers chaque adresse de l’environnement des données de cartes, ou vers un échantillon que le rapport justifie, sur chaque port et chaque protocole. Un test qui essaie les ports web et s’arrête a testé les ports web. Et vers les services partagés : l’annuaire, la plateforme de supervision, le serveur de sauvegarde, les outils d’administration. Si un contrôleur de domaine est accessible depuis le réseau des utilisateurs, ce réseau n’est pas hors périmètre, quoi que dise le pare-feu devant les serveurs de paiement.
Les détails cloud que la plupart des tests manquent
L’appairage plus une règle par défaut. Les plateformes cloud livrent une règle par défaut qui autorise le trafic entre réseaux appairés. Un schéma montre l’isolation ; la console montre tous les ports ouverts. Testez ce que dit la console.
Les groupes de sécurité qui font confiance à tout le réseau. Une règle qui accepte le trafic de toute la plage de production rend cette instance accessible depuis tout, quel que soit le nom du sous-réseau.
Les politiques datées d’après le test. Une politique réseau entrée en vigueur la semaine suivant le test n’a pas été testée. Le test prouve l’état du jour.
Les points de terminaison privés nommés comme contrôle. Un point de terminaison privé est un chemin, pas un filtre. Le groupe de sécurité ou le pare-feu est le contrôle, et c’est lui qu’il faut nommer et tester.
Ce que le rapport doit dire
La méthodologie. Les réseaux sources, par leur nom. Les cibles et la façon dont l’échantillon a été choisi. Les dates. Les outils. Les résultats, par réseau source, avec la preuve que chacun était isolé ou ne l’était pas. Qui l’a fait et pourquoi il est indépendant. Un rapport auquel il manque l’un de ces éléments est lu par un évaluateur comme « un test a peut-être eu lieu ».
Ce que l’on fait de travers
On achète une analyse d’accessibilité et on l’appelle test de segmentation. On teste le périmètre et on saute les services partagés. On oublie les réglages cloud par défaut. On lance le test une fois, avant que le réseau ne soit terminé, et plus jamais après les changements.