Le périmètre décide du coût de l’évaluation, du nombre de constats et de savoir si le rapport décrit quelque chose de réel. Voici comment il fonctionne, avec les exemples que nous rencontrons le plus, surtout dans le cloud.
Trois endroits où un système peut être
Dans l’environnement des données de cartes. Tout ce qui stocke, traite ou transmet des données de cartes, et tout ce qui est sur le même segment réseau que quelque chose qui le fait. La page de paiement, la base avec les numéros de cartes, le terminal, le commutateur qu’ils partagent.
Connecté à lui, ou capable d’affecter sa sécurité. Les systèmes qui ne touchent pas aux données de cartes mais peuvent atteindre l’environnement, ou décider de ce qui l’atteint. L’annuaire qui authentifie les administrateurs. Le coffre de clés. Le pare-feu et le moteur de règles devant l’environnement. Le service d’identité. Les ordinateurs portables des administrateurs. La chaîne de déploiement qui y pousse du code. La plateforme de supervision qui lit ses journaux. Ils sont dans le périmètre. La plupart des exigences s’y appliquent.
Hors périmètre. Les systèmes qui ne peuvent pas atteindre l’environnement, ne peuvent pas affecter sa sécurité, et dont on a prouvé, par un test de segmentation, que c’est le cas. Rien n’est hors périmètre par déclaration.
Dans le périmètre
Environnement des données de cartes (CDE)
Stocke, traite ou transmet des données de compte.
- Applications de paiement
- Bases contenant des données de cartes
- Réseaux qui les transportent
Connectés ou impactant la sécurité
Peuvent atteindre le CDE, ou affectent sa sécurité.
- Services d’annuaire
- Journalisation et supervision
- Serveurs de rebond
- Gestion des correctifs
Segmentation testée
Tous les 12 mois, tous les 6 mois pour les prestataires de services, et après chaque changement.
Hors périmètre
Systèmes isolés
Aucun chemin vers le CDE, et la segmentation le prouve.
- Réseau bureautique
- RH et finance
- Wi-Fi invités
L’erreur que nous voyons le plus
« Il ne porte pas de données de cartes, donc il est hors périmètre. » Le document de périmètre cloud d’une société de paiement ne déclarait dans le périmètre que les réseaux du cluster. Ses abonnements de concentrateur et de zone d’atterrissage étaient marqués dehors, alors qu’ils hébergeaient le coffre de clés, le service de bordure, le pare-feu et le service d’identité, que la société avait elle-même tous listés comme affectant la sécurité. L’inventaire omettait aussi les portables des administrateurs et les nœuds du cluster. Un magasin de documents qui contenait des numéros de cartes n’apparaissait pas du tout dans les flux, et la réponse à « qui peut le lire ? » était « aucun accès », sans rien dire de la façon dont les administrateurs privilégiés étaient techniquement empêchés de s’accorder cet accès.
Aucun de ces systèmes ne portait de données de cartes. Chacun d’eux pouvait décider de ce qui leur arrivait.
Écrivez le périmètre par système, pas par type de composant
« Machines virtuelles, bases de données, pare-feu » est une liste de catégories. Elle ne peut pas être vérifiée contre une configuration. Un périmètre vérifiable nomme chaque système, le place à l’un des trois endroits, dit pourquoi, et nomme le contrôle qui l’y maintient. Le périmètre confirmé de la même société, quand il est enfin arrivé, comptait vingt-deux systèmes, onze zones, vingt et un flux et sept contrôles de segmentation nommés. Le rapport a été écrit sur ce périmètre, et la société l’assumait, ce qui est le test qu’un périmètre doit passer.
Nommez les contrôles qui segmentent réellement. Un service de point de terminaison privé était cité comme contrôle de segmentation ; les groupes de sécurité réseau et le pare-feu qui filtraient effectivement le trafic n’étaient pas mentionnés. Des affirmations du document, comme « les groupes de sécurité n’autorisent que les ports web », ont été contredites ensuite par la configuration. Écrivez ce que dit la configuration, puis faites dire à la configuration ce que vous voulez.
Écrivez ce que dit la configuration, puis faites dire à la configuration ce que vous voulez.
Le groupe de sécurité qui fait entrer un système
Une instance de cache dans l’environnement cloud d’une jeune société avait un groupe de sécurité qui acceptait le trafic de tout le réseau de production. L’équipe voulait la classer « connectée ». Impossible tant que cette règle existait : si tout peut l’atteindre et qu’elle peut atteindre l’environnement des données de cartes, c’est un chemin vers l’environnement, et elle est dedans. Resserrez le groupe, et elle bouge. Le périmètre suit la configuration, pas l’intention.
Qui peut lire les données de cartes
« Aucun accès » est une affirmation sur un contrôle technique. Les questions qui en font une preuve : comment un administrateur privilégié est-il empêché de s’accorder l’accès au plan de données, et s’il le faisait, où cela serait-il journalisé, et qui lirait le journal ? Si la réponse honnête est « il le pourrait, et ça ne le serait pas », alors les administrateurs sont dans le périmètre et les données sont moins protégées que le document ne le dit.