Partager via

Exigence 11 de la norme PCI-DSS et Microsoft Entra ID

  • Article

Exigence 11 : tester régulièrement la sécurité des systèmes et des réseaux
Exigences de l’approche définie

11.1 Des processus et mécanismes destinés à tester régulièrement la sécurité des systèmes et des réseaux sont définis et compris.

Exigences d’approche définies par la norme PCI-DSS Aide et recommandations relatives à Microsoft Entra
11.1.1 L’ensemble des stratégies de sécurité et procédures opérationnelles identifiées dans la condition requise 11 sont les suivantes :
Documentées
Tenues à jour
En place
Connues de toutes les parties concernées		 Utilisez les conseils et les liens ci-dessous pour produire la documentation et répondre aux exigences en fonction de la configuration de votre environnement.
11.1.2 Les rôles et responsabilités liés à l’exécution des activités mentionnées dans l’Exigence 11 sont documentés, attribués et compris. Utilisez les conseils et les liens ci-dessous pour produire la documentation et répondre aux exigences en fonction de la configuration de votre environnement.

11.2 Les points d’accès sans fil sont identifiés et surveillés, et les points d’accès sans fil non autorisés sont traités.

Exigences d’approche définies par la norme PCI-DSS Aide et recommandations relatives à Microsoft Entra
11.2.1 Les points d’accès sans fil autorisés et non autorisés sont gérés comme suit :
la présence de points d’accès sans fil (Wi-Fi) est testée.
Tous les points d’accès sans fil autorisés et non autorisés sont détectés et identifiés.
Les tests, la détection et l’identification ont lieu au moins une fois tous les trois mois.
Si une surveillance automatisée est utilisée, le personnel est averti via des alertes générées.		 Si votre organisation intègre des points d’accès réseau à Microsoft Entra ID pour l’authentification, consultez Exigence 1 : installer et gérer des contrôles de sécurité réseau
11.2.2 Un inventaire des points d’accès sans fil autorisés est maintenant, notamment une justification métier documentée. Non applicable à Microsoft Entra ID.

11.3 Les vulnérabilités externes et internes sont régulièrement identifiées, hiérarchisées et traitées.

Exigences d’approche définies par la norme PCI-DSS Aide et recommandations relatives à Microsoft Entra
11.3.1 Des analyses de vulnérabilité internes sont effectuées comme suit :
au moins une fois tous les trois mois.
Les vulnérabilités à haut risque et critiques (selon les classements des risques de vulnérabilité de l’entité définis dans l’Exigence 6.3.1) sont résolues.
De nouvelles analyses sont effectuées pour confirmer que la résolution de toutes les vulnérabilités critiques et à haut risque (comme indiqué).
Un outil d’analyse est tenu à jour à l’aide des dernières informations sur les vulnérabilités.
Des analyses sont effectuées par du personnel qualifié et l’indépendance organisationnelle du testeur existe.		 Incluez des serveurs qui prennent en charge les fonctionnalités hybrides de Microsoft Entra. Par exemple, Microsoft Entra Connect, des connecteurs de proxy d’application, etc. dans le cadre d’analyses de vulnérabilité internes.
Organisations utilisant l’authentification fédérée : examinez et corrigez les vulnérabilités de l’infrastructure système de fédération. Qu’est-ce que la fédération avec Microsoft Entra ID ?
Passez en revue et atténuez les détections de risques signalées par Protection Microsoft Entra ID. Intégrez les signaux à une solution de Gestion des informations et des événements de sécurité (SIEM) pour l’intégrer davantage aux workflows de correction ou à une automatisation. Détection et types de risques
Exécutez régulièrement l’outil d’évaluation Microsoft Entra et traitez les résultats. AzureADAssessment
Opérations de sécurité pour l’infrastructure
Intégrer les journaux Microsoft Entra aux journaux Azure Monitor
11.3.1.1 Toutes les autres vulnérabilités applicables (celles qui ne sont pas classées comme étant à haut risque ou critiques selon les classements des risques de vulnérabilité de l’entité définis dans l’Exigence 6.3.1) sont gérées comme suit :
traitées en fonction du risque défini dans l’analyse des risques ciblés de l’entité, qui est effectuée en fonction de tous les éléments spécifiés dans l’Exigence 12.3.1.
De nouvelles analyses sont effectuées en fonction des besoins.		 Incluez des serveurs qui prennent en charge les fonctionnalités hybrides de Microsoft Entra. Par exemple, Microsoft Entra Connect, des connecteurs de proxy d’application, etc. dans le cadre d’analyses de vulnérabilité internes.
Organisations utilisant l’authentification fédérée : examinez et corrigez les vulnérabilités de l’infrastructure système de fédération. Qu’est-ce que la fédération avec Microsoft Entra ID ?
Passez en revue et atténuez les détections de risques signalées par Protection Microsoft Entra ID. Intégrez les signaux à une solution de Gestion des informations et des événements de sécurité (SIEM) pour l’intégrer davantage aux workflows de correction ou à une automatisation. Détection et types de risques
Exécutez régulièrement l’outil d’évaluation Microsoft Entra et traitez les résultats. AzureAD/AzureADAssessment
Opérations de sécurité pour l’infrastructure
Intégrer les journaux Microsoft Entra aux journaux Azure Monitor
11.3.1.2 Des analyses de vulnérabilité internes sont effectuées via une analyse authentifiée comme suit :
les systèmes ne pouvant pas accepter des informations d’identification pour l’analyse authentifiée sont documentés.
Des privilèges suffisants sont utilisés pour ces systèmes qui acceptent des informations d’identification pour une analyse.
Si des comptes utilisés pour l’analyse authentifiée peuvent l’être pour une connexion interactive, ils sont gérés conformément à l’Exigence 8.2.2.		 Incluez des serveurs qui prennent en charge les fonctionnalités hybrides de Microsoft Entra. Par exemple, Microsoft Entra Connect, des connecteurs de proxy d’application, etc. dans le cadre d’analyses de vulnérabilité internes.
Organisations utilisant l’authentification fédérée : examinez et corrigez les vulnérabilités de l’infrastructure système de fédération. Qu’est-ce que la fédération avec Microsoft Entra ID ?
Passez en revue et atténuez les détections de risques signalées par Protection Microsoft Entra ID. Intégrez les signaux à une solution de Gestion des informations et des événements de sécurité (SIEM) pour l’intégrer davantage aux workflows de correction ou à une automatisation. Détection et types de risques
Exécutez régulièrement l’outil d’évaluation Microsoft Entra et traitez les résultats. AzureADAssessment
Opérations de sécurité pour l’infrastructure
Intégrer les journaux Microsoft Entra aux journaux Azure Monitor
11.3.1.3 Des analyses de vulnérabilité internes sont effectuées après toute modification significative comme suit :
les vulnérabilités critiques et à haut risque (selon les classements des risques de vulnérabilité de l’entité défini dans l’Exigence 6.3.1) sont résolues.
De nouvelles analyses sont effectuées en fonction des besoins.
Des analyses sont effectuées par du personnel qualifié et une indépendance organisationnelle du testeur existe (il n’est pas nécessaire d’être un évaluateur de sécurité qualifié (QSA) ou un prestataire d’analyses agréé (ASV)).		 Incluez des serveurs qui prennent en charge les fonctionnalités hybrides de Microsoft Entra. Par exemple, Microsoft Entra Connect, des connecteurs de proxy d’application, etc. dans le cadre d’analyses de vulnérabilité internes.
Organisations utilisant l’authentification fédérée : examinez et corrigez les vulnérabilités de l’infrastructure système de fédération. Qu’est-ce que la fédération avec Microsoft Entra ID ?
Passez en revue et atténuez les détections de risques signalées par Protection Microsoft Entra ID. Intégrez les signaux à une solution de Gestion des informations et des événements de sécurité (SIEM) pour l’intégrer davantage aux workflows de correction ou à une automatisation. Détection et types de risques
Exécutez régulièrement l’outil d’évaluation Microsoft Entra et traitez les résultats. AzureADAssessment
Opérations de sécurité pour l’infrastructure
Intégrer les journaux Microsoft Entra aux journaux Azure Monitor
11.3.2 Des analyses de vulnérabilité internes sont effectuées comme suit :
au moins une fois tous les trois mois.
Par un prestataire d’analyses agréé (ASV) PCI SSC.
Les vulnérabilités sont résolues et les exigences du Guide du programme ASV pour une analyse de réussite sont satisfaites.
Des analyses sont effectuées, en fonction des besoins, pour confirmer que les vulnérabilités sont résolues conformément aux exigences du Guide du programme ASV pour une analyse de passage.		 Non applicable à Microsoft Entra ID.
11.3.2.1 Des analyses de vulnérabilité externes sont effectuées après toute modification significative comme suit :
les vulnérabilités dont le score est égal ou supérieur à 4.0 par le CVSS sont résolues.
De nouvelles analyses sont effectuées en fonction des besoins.
Des analyses sont effectuées par du personnel qualifié et l’indépendance organisationnelle du testeur existe (il n’est pas requis d’être un QSA ou un ASV).		 Non applicable à Microsoft Entra ID.

11.4 Des tests d’intrusion externes et internes sont régulièrement effectués et les vulnérabilités exploitables et les failles de sécurité sont corrigées.

Exigences d’approche définies par la norme PCI-DSS Aide et recommandations relatives à Microsoft Entra
11.4.1 Une méthodologie de test d’intrusion est définie, documentée et implémentée par l’entité, et inclut :
des approches de test d’intrusion acceptées par le secteur d’activité.
Couverture pour l’ensemble du périmètre de l’environnement CDE et des systèmes critiques.
Tests à partir de l’intérieur et l’extérieur du système.
Tests permettant de valider des contrôles de segmentation et de réduction de l’étendue.
Tests de pénétration de couche d’application permettant d’identifier, au minimum, les vulnérabilités indiquées dans la l’Exigence 6.2.4.
Tests de pénétration de couche d’application permettant d’englober des composants qui prennent en charge des fonctions réseau et des systèmes d’exploitation.
Examen et prise en compte des menaces et des vulnérabilités rencontrées au cours des 12 derniers mois.
Approche documentée permettant d’évaluer et de résoudre le risque posé par des vulnérabilités exploitables et des faiblesses de sécurité détectées lors de tests d’intrusion.
Conservation des résultats de tests de pénétration et des résultats des activités de correction pendant au moins 12 mois.		 Règles d’engagement des tests d’intrusion de Cloud Microsoft
11.4.2 Des tests d’intrusion internes sont effectués :
selon la méthodologie définie par l’entité.
Au moins une fois tous les 12 mois.
Après toute mise à niveau ou modification importante de d’une infrastructure ou d’une application.
Par une ressource interne qualifiée ou un tiers externe qualifié.
L’indépendance organisationnelle du testeur existe (il n’est pas nécessaire d’être un QSA ou un ASV).		 Règles d’engagement des tests d’intrusion de Cloud Microsoft
11.4.3 Des tests d’intrusion externes sont effectués :
selon la méthodologie définie par l’entité.
Au moins une fois tous les 12 mois.
Après toute mise à niveau ou modification importante de d’une infrastructure ou d’une application.
Par une ressource interne qualifiée ou un tiers externe qualifié.
L’indépendance organisationnelle du testeur existe (il n’est pas nécessaire d’être un QSA ou un ASV).		 Règles d’engagement des tests d’intrusion de Cloud Microsoft
11.4.4 Les vulnérabilités exploitables et les faiblesses de sécurité détectées pendant des tests d’intrusion sont corrigées comme suit :
conformément à l’évaluation par l’entité du risque posé par le problème de sécurité tel que défini dans l’Exigence 6.3.1.
Des tests d’intrusion sont répétés pour vérifier les corrections.		 Règles d’engagement des tests d’intrusion de Cloud Microsoft
11.4.5 Si une segmentation est utilisée pour isoler le CDE d’autres réseaux, des tests d’intrusion sont effectués sur des contrôles de segmentation comme suit :
au moins une fois tous les 12 mois et après toute modification des contrôles/méthodes de segmentation.
Couverture de tous les contrôles/méthodes de segmentation utilisés.
En fonction de la méthodologie de test d’intrusion définie de l’entité.
Confirmation que les contrôles/méthodes de segmentation sont opérationnels et efficaces et isolation du CDE de tous les systèmes hors de l’étendue.
Confirmation de l’efficacité de toute utilisation de l’isolation pour séparer des systèmes avec des niveaux de sécurité différents (voir Exigence 2.2.3).
Effectué par une ressource interne qualifiée ou un tiers externe qualifié.
L’indépendance organisationnelle du testeur existe (il n’est pas nécessaire d’être un QSA ou un ASV).		 Non applicable à Microsoft Entra ID.
11.4.6 Exigence supplémentaire pour les fournisseurs de services uniquement : si une segmentation est utilisée pour isoler le CDE d’autres réseaux, des tests d’intrusion sont effectués sur des contrôles de segmentation comme suit :
au moins une fois tous les six mois et après toute modification des contrôles/méthodes de segmentation.
Couverture de tous les contrôles/méthodes de segmentation utilisés.
En fonction de la méthodologie de test d’intrusion définie de l’entité.
Confirmation que les contrôles/méthodes de segmentation sont opérationnels et efficaces et isolation du CDE de tous les systèmes hors de l’étendue.
Confirmation de l’efficacité de toute utilisation de l’isolation pour séparer des systèmes avec des niveaux de sécurité différents (voir Exigence 2.2.3).
Effectué par une ressource interne qualifiée ou un tiers externe qualifié.
L’indépendance organisationnelle du testeur existe (il n’est pas nécessaire d’être un QSA ou un ASV).		 Non applicable à Microsoft Entra ID.
11.4.7 Exigence supplémentaire pour les fournisseurs de services multilocataires uniquement : les fournisseurs de services multilocataires prennent en charge leurs clients pour des tests d’intrusion externes conformément aux Exigences 11.4.3 et 11.4.4. Règles d’engagement des tests d’intrusion de Cloud Microsoft

11.5 Les intrusions réseau et les modifications inattendues apportées à des fichiers sont détectées et traitées.

Exigences d’approche définies par la norme PCI-DSS Aide et recommandations relatives à Microsoft Entra
11.5.1 Des techniques de détection et/ou de prévention des intrusions sont utilisées pour détecter et/ou empêcher des intrusions dans le réseau comme suit :
tout le trafic est surveillé au niveau du périmètre du CDE.
Tout le trafic est surveillé à des points critiques dans le CDE.
Le personnel est alerté en cas de compromission présumée.
Tous les moteurs de prévention et d’intrusion-détection, les lignes de base et les signatures sont tenus à jour.		 Non applicable à Microsoft Entra ID.
11.5.1.1 Exigence supplémentaire pour les fournisseurs de services uniquement : les techniques de prévention et de détection des intrusions détectent, alertent/empêchent et traitent des canaux secrets de communication de programmes malveillants. Non applicable à Microsoft Entra ID.
11.5.2 Un mécanisme de détection des modifications (par exemple, des outils de surveillance de l’intégrité de fichiers) est déployé comme suit :
pour alerter le personnel en cas de modification non autorisée (notamment des modifications, des ajouts et des suppressions) de fichiers critiques.
Pour effectuer des comparaisons de fichiers critiques au moins une fois par semaine.		 Non applicable à Microsoft Entra ID.

11.6 des modifications non autorisées dans des pages de paiement sont détectées et traitées.

Exigences d’approche définies par la norme PCI-DSS Aide et recommandations relatives à Microsoft Entra
11.6.1 Un mécanisme de détection des modifications et des falsifications est déployé comme suit :
pour alerter le personnel en cas de modification non autorisée (notamment des indicateurs de compromission, de modifications, d’ajouts et de suppressions) d’en-têtes HTTP et du contenu de pages de paiement reçues par le navigateur du consommateur.
Le mécanisme est configuré pour évaluer l’en-tête HTTP reçu et la page de paiement.
Les fonctions du mécanisme sont effectuées comme suit : au moins une fois tous les sept jours
OU
périodiquement à la fréquence définie dans l’analyse des risques ciblés de l’entité, qui est effectuée en fonction de l’ensemble des éléments		 Non applicable à Microsoft Entra ID.

Étapes suivantes

Les exigences 3, 4, 9 et 12 de la norme PCI-DSS ne s’appliquent pas à Microsoft Entra ID. Par conséquent, il n’existe aucun article correspondant. Pour consulter toutes les exigences, rendez-vous sur le site pcisecuritystandards.org : Site officiel du Conseil des normes de sécurité PCI.

Pour configurer Microsoft Entra ID pour qu'il soit conforme à PCI-DSS, consultez les articles suivants.