Si la segmentation est fausse, tout ce qui est évalué ensuite repose sur le mauvais périmètre. C’est pourquoi nous validons le périmètre et la segmentation avant de regarder toute autre exigence, et pourquoi un test de segmentation faible n’est jamais un petit constat.
Le propre réseau du testeur avait accès
Une société de paiement e-commerce comptait sur la segmentation pour garder l’essentiel de son parc cloud hors périmètre. Le test de segmentation fourni avait été lancé depuis une seule machine de rebond, sur un réseau que le rapport n’identifiait pas, vers un échantillon de seize adresses de l’environnement des données de cartes. De l’accessibilité depuis un point, rien de plus.
Pendant ce temps, l’export de la console de la société racontait autre chose. Deux réseaux appairés, l’un appartenant à la société de test elle-même, l’autre à un fournisseur de flux de données, tous deux classés comme non fiables par la société, pouvaient atteindre le sous-réseau des conteneurs sur tous les ports. La règle par défaut de la plateforme cloud autorisant le trafic entre réseaux appairés n’avait jamais été remplacée. La politique réseau fournie comme preuve est entrée en vigueur huit jours après le test. Le dossier de périmètre citait aussi un second test de segmentation dont aucun rapport n’existait.
L’exigence 11.4.5 n’était pas en place. Pour la clore : corriger les règles d’appairage, puis tester depuis chaque réseau hors périmètre, pas depuis un seul. Nous avons aussi placé un test d’intrusion interne au niveau réseau en tête du plan de remédiation, parce que des réseaux appairés atteignant l’environnement des données de cartes sur tous les ports, et un service non approuvé en écoute sur un nœud, sont exactement ce qu’un tel test est conçu pour trouver.
Tester la porte d’entrée pendant que la porte de derrière est ouverte
Un groupe de centres d’appels présent dans cinq pays a vu sa méthodologie de test de segmentation rejetée à la fin d’une évaluation annuelle et a dû la refaire. Le problème de fond avait été signalé comme critique l’année précédente : les services partagés, l’annuaire et d’autres serveurs critiques, n’étaient pas protégés des réseaux hors périmètre, et le bureau à distance entrant n’était pas restreint. Sur un site, un jeu de règles de pare-feu personnel autorisait l’accès à l’environnement des données de cartes depuis la plateforme d’enregistrement des appels, sans authentification multifacteur.
Tester la porte d’entrée de l’environnement des données de cartes pendant que le contrôleur de domaine d’à côté est accessible depuis le réseau des utilisateurs n’est pas un test de segmentation. Si un contrôleur de domaine est accessible depuis un réseau, ce réseau n’est pas hors périmètre. Les analyses internes racontaient la même histoire : elles couvraient 104 des 261 systèmes d’un site et 212 des 760 d’un autre.
La façon dont celle-ci s’est terminée mérite d’être racontée, parce que ce n’était pas à nous de décider. Le plus grand client du groupe a jugé que le risque pour ses données de cartes était faible, et a choisi trente-quatre exigences à nous faire évaluer : l’essentiel de l’exigence 12, une exigence sur les revues d’accès, une sur le retrait des accès des personnes parties. Aucune identification du périmètre. Le propre QSA du client lui a conseillé qu’une lettre couvrant sa responsabilité, évoquant à peine le consentement de son acquéreur, était la voie à suivre. Nous pensons que c’est une erreur. L’environnement traite encore des données de cartes dès que le serveur vocal habituel n’est pas utilisé, en petit volume, mais pas zéro. Nous l’avons dit. Puis on nous a demandé de livrer un rapport partiel sur ces trente-quatre contrôles, et nous avons livré exactement cela, et rien de plus. Nous n’écrivons pas les règles. Quand ceux qui portent le risque choisissent de les restreindre, nous disons ce que nous en pensons, par écrit, et nous évaluons ce que l’on nous a demandé d’évaluer.
Si un contrôleur de domaine est accessible depuis un réseau, ce réseau n’est pas hors périmètre.
Segmentation déclarée, jamais testée
Une plateforme de paiement a été évaluée alors qu’elle était encore en construction. L’analyse d’écart notait que la segmentation était « déclarée en place », et qu’aucun résultat de test n’avait été fourni. Le premier Report on Compliance a ensuite cité des failles dans la méthodologie de test de la segmentation parmi les raisons pour lesquelles le périmètre ne pouvait pas être validé, à côté de schémas réseau qui changeaient pendant l’évaluation. Le périmètre et la segmentation devaient être validés avant d’évaluer toute autre exigence. Le rapport conforme a suivi deux mois plus tard, une fois la plateforme en production et le test fait correctement.
Ce que l’on fait de travers
On prend un contrôle d’accessibilité depuis un point pour un test de segmentation. L’exigence demande l’isolation vis-à-vis de chaque réseau hors périmètre. Un rebond sur un réseau répond pour un réseau.
On oublie les réglages cloud par défaut. Un appairage plus une règle d’autorisation par défaut défont discrètement le schéma. Le schéma montre l’isolation ; la console montre tous les ports ouverts. C’est la console qui a raison.
On teste le périmètre et on ignore les services partagés. L’annuaire, la plateforme de supervision, le serveur de sauvegarde et les outils d’administration sont des deux côtés de chaque frontière. S’ils sont accessibles depuis un réseau hors périmètre, la frontière est un trait sur une diapositive.
On fournit une politique datée d’après le test. Le test prouve l’état du réseau ce jour-là. Une règle entrée en vigueur la semaine suivante n’a pas été testée.