Avant de commencer, téléchargez le document PDF Checklist pour la conformité PCI et continuez !
Table des matières
- Brève description :
- Mises à jour de la version 3.2 – Ce que vous devez savoir
- Le programme en 12 étapes de la PCI simplifié
Brève description :
La conformité à la norme PCI DSS est obligatoire pour toute entreprise qui stocke, traite ou transmet des données de titulaires de cartes de paiement. Il peut être laborieux de chercher parmi les centaines de pages et sous-exigences délivrées par le Conseil des normes de sécurité (SSC, pour Security Standards Council). Si vous ajoutez à cela quelques mises à jour, nous nous trouvons face à une véritable montagne de paperasse.
Pour reprendre l’expression d’un célèbre Guide galactique : « pas de panique ! »
Ce guide et la checklist qui l’accompagne vous guideront sur la voie de la conformité à la norme PCI DSS 3.2. Découvrez les changements apportés par la version 3.2, la manière d’aborder les 12 exigences de la PCI en matière de conformité, ainsi que les choses à faire et les choses à éviter au cours de ce processus.
Exigences de la norme PCI DSS 3.2 en termes d’évolution – Examen de haut vol
La récente mise à jour de la norme PCI DSS 3.2 s’accompagne d’une multitude de changements et de clarifications. Prenons un peu de hauteur pour survoler ces points.
Nouveaux délais de conformité – A vos calendriers
1er novembre 2016
La norme PCI DSS 3.1 prendra sa retraite au premier novembre. A compter de cette date, toutes les évaluations seront basées sur la norme 3.2.
1er février 2018
Plusieurs exigences en termes d’évolution ont été énoncées dans la norme 3.2 (voir plus bas). Les exigences supplémentaires seront considérées comme des bonnes pratiques jusqu’au 1er février 2018, date à laquelle elles deviendront des exigences de conformité.
1er juillet 2018
À l’heure actuelle, les versions 1.0 et antérieures des technologies SSL et TLS ne sont plus des protocoles de sécurité protégés. La mise en application des nouveaux protocoles sera considérée comme faisant partie des bonnes pratiques jusqu’en 2018, où elle deviendra une exigence. Remarque* – La norme PCI DSS 3.1 avait préalablement fixé la date limite au 30 juin 2016, mais la norme 3.2 a prolongé ce délai.
A FAIRE :
- Migrer au plus tôt vers une version actualisée du protocole de sécurité TLS.
A EVITER :
- Attendre la date limite du 1er juillet 2018 pour procéder à cet ajustement. Même si conserver les technologies SSL/prédécesseur de TLS en 2016 et 2017 ne constitue pas une non-conformité, le Conseil des normes de sécurité de l’industrie des cartes de paiement (PCI) a déterminé que ces protocoles n’étaient plus sûrs. Pourquoi risquer une violation de la sécurité ?
L’authentification multifacteurs pour tous (8.3)
La norme PCI DSS 3.2 a remplacé l’exigence d’authentification à deux facteurs par une authentification multifacteurs, afin de clarifier le fait que vous n’étiez pas limité à deux facteurs seulement. En outre, cette exigence ne s’applique plus aux seuls employés travaillant à distance, mais à toute personne dotée d’un accès administrateur non-console à l’environnement des données du titulaire (CDE, pour « cardholder data environment »), quel que soit son emplacement.
Pour être en conformité, vous devez choisir au moins 2 de ces méthodes d’authentification :
- quelque chose que vous savez, par exemple un mot/une phrase de passe ;
- quelque chose que vous détenez, par exemple un dispositif de jeton ou une carte à puce ;
- quelque chose qui vous est propre, par exemple une empreinte digitale ou un scan rétinien.
Masquage et visibilité du PAN ou numéro de compte primaire (3.3)
La norme PCI DSS 3.2 précise que les numéros de compte primaires doivent être masqués lorsqu’ils s’affichent, ce qui signifie que les 6 premiers chiffres et les 4 derniers sont le maximum de chiffres affichés. Une liste répertoriant les rôles des employés qui ont besoin d’accéder à plus de chiffres que ne le permet le PAN masqué doit être créée, et indiquer la raison pour laquelle chaque rôle a besoin de disposer de cet accès.
A FAIRE :
- S’assurer que des exigences plus strictes ne prévalent pas sur la limite de masquage du PAN énoncée ci-dessus (par ex., des marques de carte qui limitent le masquage du PAN pour les reçus des points de vente).S’assurer que des exigences plus strictes ne prévalent pas sur la limite de masquage du PAN énoncée ci-dessus (par ex., des marques de carte qui limitent le masquage du PAN pour les reçus des points de vente).
A EVITER :
- Afficher le nombre maximum de premiers et derniers chiffres (6 et 4) s’il ne s’agit pas d’une nécessité commerciale.
- Solution : déterminer le nombre minimum de chiffres du PAN dont votre organisation a besoin pour fonctionner et masquer le reste.
Des rapports plus stricts pour les prestataires de services
La norme PCI DSS 3.2 a introduit plusieurs nouvelles exigences applicables aux prestataires de services et a également inclus la Designated Entities Supplemental Validation (DESV) en annexe. Par contre, ce sont les marques de paiement qui décident qu’un prestataire de services est tenu de se conformer à la validation DESV supplémentaire.
Chaque chose en son temps : que doivent faire tous les prestataires de services ?
A FAIRE :
- Interroger le personnel pour s’assurer que l’architecture cryptographique est documentée et que les contrôles de sécurité détectent les défaillances système critiques et alertent les propriétaires de données concernés. (3.5.1, 10.8)
- Créer une procédure de gestion des modifications qui documente les modifications apportées au système ainsi que leur impact sur les exigences PCI DSS. (6.4.6)
- Réparer immédiatement les défaillances des contrôles de sécurité, documenter la durée de la défaillance, sa cause, les résultats de l’évaluation des risques et les nouveaux contrôles destinés à éviter des défaillances futures. (10.8.1)
- (Si vous utilisez la segmentation) Mettre en œuvre des tests de pénétration pour les contrôles de segmentation après toute modification importante ou au minimum tous les 6 mois. (11.3.4.1)
- Procéder à des analyses trimestrielles (au minimum) afin de s’assurer que le personnel respecte les politiques et procédures de sécurité. (12.11)
*Remarque : La norme PCI DSS 3.2 stipule que le personnel doit être contrôlé en ce qui concerne l’examen des journaux quotidiens, l’examen des règles de pare-feu, l’application des normes de configuration aux nouveaux systèmes, les réponses aux alertes de sécurité et la conformité aux procédures de gestion des modifications.
- Documenter les résultats des examens trimestriels, y compris les signatures du personnel responsable du programme de conformité à la norme PCI DSS. (12.11.1)
- S’assurer que les cadres supérieurs définissent les responsabilités en termes de protection des données de titulaires et de conformité à la norme PCI DSS 3.2, y compris une déclaration de responsabilité pour tous les prestataires de services. (12.4.1, 12.8.2)
Si un acquéreur ou une marque de paiement détermine qu’un prestataire de services a besoin d’une validation DESV supplémentaire, qu’est-ce que cela signifie ?
La DESV garantit avec plus de certitude que les prestataires de services procèdent à des contrôles PCI DSS de manière régulière et plus efficace. Les 5 étapes de validation détaillées dans la DESV sont extrêmement similaires aux nouvelles exigences du prestataire de services : mise en œuvre d’un programme PCI DSS, contrôle de l’accès à l’environnement des données du titulaire, etc. La DESV a en quelque sorte le rôle d’encadrant contrôlant la bonne exécution de la norme PCI DSS. La DESV vous guide à travers toutes les étapes de l’élaboration d’un programme de conformité à la norme PCI DSS et recommande des vérifications constantes, afin de garantir que les initiatives sont suivies de manière cohérente, jusqu’à l’élaboration de rapports sur les comptes rendus de réunions.
Vous pouvez accéder à l’intégralité de la DESV sur le site PCI SSC.
Le programme de la PCI simplifié en 12 exigences
La PCI DSS énonce ses exigences en 12 grandes étapes. Voilà qui semble tout simple, n’est-ce pas ? Projetez-vous 139 pages en police de 10 plus loin, au moment où vous vous demandez : « qu’est-ce que je viens de lire ? »
Prenons un peu de recul et voyons si nous pouvons regrouper ces exigences pour concocter quelque chose de plus digeste. Et si nous élaborions 4 tactiques de défense décomposées en checklists ? Nous vous conseillons de télécharger gratuitement notre checklist au format PDF afin de suivre votre progression.
Protégez les données des titulaires de carte
La première étape s’impose comme une évidence. Elle concerne exclusivement les données de carte de crédit client, alors assurons-nous que les données elles-mêmes sont en sécurité avant de travailler sur le périmètre.
Exigences DSS applicables :
Exigence DSS 3 – Protéger les données du titulaire stockées
A FAIRE :
- Appliquer des politiques documentées de conservation et d’élimination des données afin de limiter la collecte et la durée de conservation des données de titulaire. (3.1)
- Interroger vos employés pour vérifier que les politiques sont suivies et que des procédures trimestrielles sont en place pour éliminer les données du titulaire, en dehors de votre politique de conservation. (3.1.b)
- S’assurer que les données stockées et les données en transit sont illisibles. (3.4, 4.1)
- Crypter les données de carte et protéger les clés cryptées. (3.5)
- Masquer vos données PAN lorsqu’elles doivent être vues (voir plus haut) en utilisant le moins de chiffres possible (afficher moins que les 6 premiers et les 4 derniers). (3.3)
- Créer un diagramme des flux relatifs au titulaire de carte pour tous les flux de données à travers votre organisation. (1.1.3)
- Utiliser un outil de découverte de données pour repérer les données sensibles mal placées dans votre environnement.
A EVITER :
- Stocker des données d’identification sensibles après autorisation. (3.2)
- Exception : votre organisation est émettrice et dispose d’une justification commerciale.
- Stocker des données PAN masquées.
- Solution : les crypter.
Exigence DSS 4 – Crypter la transmission des données du titulaire sur les réseaux publics ouverts
A FAIRE :
- Identifier la destination des données du titulaire et s’assurer que vos polices ne font pas l’objet d’une violation sur le trajet et que ne sont utilisés que des clés ou des certificats fiables. (4.1)
- Sélectionner un échantillon de transmissions entrantes et sortantes et vérifier que la cryptographie est maintenue lors du transit. (4.1.c)
A EVITER :
- Envoyer des PAN par technologie de messagerie utilisateur final, par exemple courrier électronique, SMS ou messagerie instantanée. (4.2)
- Employer de nouvelles technologies utilisant les protocoles SSL/prédécesseur de TLS. (version 1.0 ou antérieure)
- Faire migrer les données du titulaire vers des systèmes utilisant SSL/prédécesseur de TLS. (version 1.0 ou antérieure)
Protégez-vous contre les menaces externes
Vos données en elles-mêmes sont donc maintenant protégées. Elles sont cryptées, masquées lorsqu’elles doivent être affichées et ne voyagent que via des flux de données de titulaire mappés. Malheureusement, cela ne suffit pas complètement à protéger vos données de titulaire. Au-delà du périmètre de votre environnement, se trouve un univers effrayant, peuplé de méchants pirates et usurpateurs.
La norme PCI DSS vise à s’assurer que vous bâtissez des murs hauts et solides (je vous promets de ne pas abuser de ces métaphores sur les châteaux-forts) en renforçant vos pare-feu et vos protections anti-virus, en modifiant les paramètres de sécurité par défaut et en maintenant la sécurité des systèmes grâce à une procédure de contrôle des modifications solide.
Exigences DSS applicables :
Exigence DSS 1 : Installer et gérer une configuration de pare-feu pour protéger les données du titulaire
A FAIRE :
- Installer un pare-feu au niveau de chaque connexion Internet (chaque appareil) et entre toute zone démilitarisée (DMZ) et la zone de réseau interne (1.1.4, 1.4)
- Configurer vos pare-feu avec une description des groupes responsables des composants réseau et une justification professionnelle pour tous les services/protocoles/ports de la configuration. (1.1.5, 1.1.6)
- Examiner la configuration des pare-feu et des routeurs au moins tous les 6 mois et s’assurer que tout trafic autre, non configuré (entrant ou sortant) est refusé. (1.1.7, 1.2.1)
- Créer des configurations de routeurs qui bloquent les connexions entre les parties non approuvées du réseau et les données de titulaire. (1.2, 1.3)
- Charger quelqu’un de vérifier chaque jour les journaux de pare-feu.
A EVITER :
- Stocker les données de titulaire de carte dans le DMZ ou tout réseau non fiable.
- Solution : créer une zone de réseau interne sécurisée. (1.3.6)
Exigence DSS 2 – Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur
A FAIRE :
- Identifier un administrateur système responsable des composants système. (2.2.4)
- Maintenir un inventaire de tous les composants du système qui se trouvent dans le champ d’application de la norme PCI DSS. (2.4)
- Documenter les politiques de modification des mots de passe par défaut définis par le fournisseur, des paramètres sans fil par défaut et supprimer les comptes par défaut avant d’installer un système sur votre réseau. (2.1, 2.1.1, 2.5)
- Documenter les normes de configuration des composants système relatives aux failles de sécurité, limiter les accès au service/protocole en fonction des besoins et suivre des normes de plus en plus strictes. (2.2, 2.2.2)
A EVITER :
- Mettre en applications plusieurs fonctions sur un même serveur, car cela risque de créer des conflits de permission. (2.2.1)
- Partir du principe que vos fournisseurs maintiennent une recherche anti-virus.
- Exigence : Il est de votre responsabilité de vous assurer que les fournisseurs sont à jour et procèdent à des scans réguliers.
Exigence DSS 5 – Protéger tous les systèmes contre les logiciels malveillants et mettre à jour régulièrement les logiciels ou programmes anti-virus
A FAIRE :
- Mettre à jour régulièrement les logiciels antivirus sur les systèmes fréquemment affectés et déterminer si d’autres systèmes sont en danger/ont besoin d’un anti-virus. (5.1, 5.1.1, 5.1.2)
- Automatiser les scans anti-virus et maintenir des journaux d’audit anti-virus pour vos systèmes. (5.2)
- S’assurer que seuls les administrateurs peuvent modifier ou désactiver les anti-virus. (5.3)
- Documenter les procédures de protection contre les logiciels malveillants. (5.4)
A EVITER :
- Attendre, pour identifier un logiciel malveillant, de constater les dégâts qu’il cause.
- Solution : installer un logiciel capable d’observer les anomalies de comportement et d’alerter le personnel concerné.
Exigence DSS 6 – Développer et gérer des systèmes et des applications sécurisés
A FAIRE :
- Mettre en place une procédure pour vous tenir informé des derniers points faibles de la sécurité et identifier le niveau de risque. (6.1)
- Installer tous les correctifs de sécurité développés par les fournisseurs. (6.2.a)
- Documenter l’impact, les parties autorisées, le test de fonctionnalité et les procédures d’annulation de toutes les procédures de contrôle des modifications. (6.4.5)
- Utiliser des procédures de développement strictes et des pratiques de codage sécurisées (6.3)
A EVITER :
- Attendre plus d’un mois pour installer les correctifs de sécurité développés par les fournisseurs pour les niveaux de risques identifiés comme critiques. (6.2.b)
- Tester les logiciels développés en interne dans votre environnement de production, utiliser des données de production lors des tests ou laisser les comptes/identifiants de test après la publication du logiciel. (6.3.1, 6.4.1, 6.4.3)
Protégez-vous contre les menaces internes
Les données du titulaire ont été sécurisées. La barrière externe a été renforcée. Nous pouvons tout remballer, cela suffit pour aujourd’hui, non ? Non, car il est aussi possible que l’ennemi soit parmi nous.
La violation interne peut parfois provenir d’une personne infiltrée, qui a rejoint l’organisation dans l’unique but d’exploiter les données, ou d’un traitre qui a changé intentionnellement d’équipe (si vous aviez su, vous n’auriez pas fait cette mauvaise blague à propos du bermuda que Bob porte les vendredis). Comme souvent, il s’agit donc d’un employé qui a accidentellement accès à plus de données qu’il ne le devrait et qui crée sans le savoir une faille de sécurité.
La norme PCI DSS établit plusieurs exigences visant à combattre les risques liés aux menaces internes en limitant à la fois l’accès virtuel et physique aux données du titulaire dans l’organisation.
Exigences DSS applicables :
Exigence DSS 7 : Restreindre l’accès aux données du titulaire aux seuls individus qui doivent les connaître
A FAIRE :
- Créer une liste des rôles ayant accès à l’environnement des données du titulaire comprenant la définition de chaque rôle, leur niveau de privilège et les permissions nécessaires pour permettre à chaque rôle de fonctionner. (7.1, 7.3)
- Créer une liste des moindres privilèges pour tous les employés et un paramètre « refuser tous » pour tous les paramètres de contrôle d’accès (7.1.2, 7.2.3)
- Demander l’approbation documentée des parties autorisées pour l’affectation ou la modification des privilèges dans le CDE. (7.1.4)
A EVITER :
- Donner des permissions excessives à un rôle à l’occasion de cette « sale journée » où ils peuvent en avoir besoin.
- Solution : utiliser un modèle de moindres privilèges accordant des permissions uniquement en fonction des besoins professionnels.
- Solution : octroyer l’accès uniquement pour la période nécessaire.
Exigence DSS 8 – Identifier et authentifier l’accès aux composants du système
A FAIRE :
- Définir et documenter des procédures d’identification et d’authentification de l’utilisateur sur tous les composants du système. (8.1, 8.4)
- Affecter aux utilisateurs un identifiant unique, tester les contrôles des privilèges et révoquer l’accès des utilisateurs inactifs/qui ne travaillent plus pour la société. (8.1.1, 8.1.2, 8.1.3, 8.1.4)
- Surveiller tous les comptes utilisés par les fournisseurs et autres tiers, puis les désactiver lorsqu’ils ne sont plus utilisés. (8.1.5)
- Verrouiller l’identifiant utilisateur pendant 30 minutes après six tentatives d’accès échouées. (8.1.6, 8.1.7)
- Suivre les directives relatives aux bonnes pratiques énoncées dans la norme DSS en matière de définition de mots de passe, y compris la composition d’un mot de passe robuste, le codage des informations d’authentification, la vérification de l’identifiant avant réinitialisation et une réinitialisation tous les 90 jours. (8.2.1, 8.2.2, 8.2.3, 8.2.4)
- Incorporer l’identification multifacteurs pour tous les accès administrateur non-console et les accès distants au CDE. (8.3)
A EVITER :
- Utiliser le même mot de passe pour plusieurs comptes ou appareils, si l’un d’entre eux est compromis, ils le seront tous.
- Utiliser des identifiants utilisateur ou des méthodes d’authentification partagés dans le CDE. (8.5)
Exigence DSS 9 – Restreindre l’accès physique aux données du titulaire
A FAIRE : (le cas échéant)
- Documenter la procédure régissant l’accès physique aux systèmes CDE, dresser une liste de tous les appareils, en limitant l’accès aux rôles qui en ont besoin et en contrôlant l’ensemble grâce à des jetons d’autorisation et à la mise en place d’une surveillance. (9.1.1a, 9.1.1b, 9.2, 9.3, 9.9.1)
- Créer une autorisation visiteurs et des contrôles d’accès qui garantissent que les visiteurs sont identifiés, documentés et surveillés dans les zones ayant accès à l’environnement du titulaire de carte. (9.4)
- Mettre en place des contrôles rigoureux pour les supports physiques introduits dans les locaux, utiliser le courrier suivi pour les supports sortant des locaux et s’assurer que les supports détruits ne peuvent pas être reconstitués. (9.5, 9.6, 9.8)
- Former les employés aux processus d’identification des fournisseurs externes nécessitant un accès physique et identifier/signaler les comportements suspects. (9.9.2, 9.9.3)
Protégez-vous contre l’excès de confiance
Nous avons sécurisé les données de titulaire elles-mêmes. Le périmètre a été renforcé contre les menaces externes. Des mesures ont été mises en place pour lutter contre la menace que représentent les violations internes. Quels dangers pourraient encore subsister ? L’excès de confiance.
Il ne suffit pas de parvenir à la conformité PCI pour votre évaluation. La norme PCI DSS 3.2 reconnait cela et ses exigences stipulent un renforcement de la surveillance de l’accès à toutes les ressources réseau, la pratique de tests réguliers des politiques et l’élaboration de programmes qui garantissent une implication permanente du personnel.
Exigences DSS applicables :
Exigence DSS 10 – Suivre et surveiller tous les accès aux ressources réseau et aux données du titulaire
A FAIRE :
- Mettre en œuvre des pistes d’audit pour tous les systèmes, des alertes en cas d’activité suspecte et un plan d’intervention pour ces anomalies. (10.1, 10.2, 10.6.2.b)
- Suivre toutes les actions des administrateurs, les tentatives de connexion, les modifications de compte et les pauses dans les pistes d’audit. (10.2.3, 10.2.4, 10.2.5, 10.2.6)
- S’assurer que chaque journal d’audit consigne l’identifiant utilisateur, le type d’événement, la date et l’heure, la réussite ou l’échec de l’événement, son origine et les ressources affectées. (10.3)
- Conserver l’ensemble des journaux d’audit pour une durée minimale d’un an, avec les 3 derniers mois disponibles pour analyse. (10.7)
- Éviter la manipulation des pistes d’audit et utiliser un logiciel pour signaler les modifications des journaux. (10.5)
- Élaborer une procédure qui examine chaque jour les journaux système des CHD et une procédure qui examine tous les autres composants système en fonction des résultats de votre analyse des risques. (10.6.1, 10.6.2)
A EVITER :
- Donner accès au journal d’audit à n’importe qui sans justification liée au rôle. (10.5.1)
- Procéder à l’examen quotidien des pistes d’audit à l’aide d’une méthode manuelle ; la perte de temps peut être importante.
- Stocker les journaux d’audit pour les technologies ouvertes au public sur ces machines ; leur sécurité peut être compromise. (10.5.4)
Exigence DSS 11 – Tester régulièrement les processus et les systèmes de sécurité
A FAIRE :
- Documenter chaque point d’accès sans fil autorisé avec une justification professionnelle. (11.1.1)
- Mettre en œuvre des procédures visant à tester les points d’accès sans fil autorisés et non autorisés chaque trimestre et à prendre les mesures appropriées. (11.1, 11.1.2)
- Effectuer des scans de vulnérabilité internes (avec un personnel qualifié) et externes (avec un fournisseur de service de scan approuvé, ASV pour Approved Scanning Vendor) chaque trimestre et à chaque modification importante du réseau, en corrigeant et en scannant à nouveau toutes les vulnérabilités identifiées. (11.2)
- Exécuter une fois par an des tests de pénétration internes et externes (avec un personnel qualifié ou des tiers) en corrigeant et testant à nouveau tout risque exploitable détecté. (11.3)
- Déployer un outil de détection de changement pour alerter le personnel de toute modification non autorisée des fichiers critiques du système et effectuer des comparaisons de fichier critique au moins une fois par semaine. (11.5)
- Mettre en œuvre un processus pour répondre aux alertes générées par la solution de détection de changement. (11.5.1, 11.6)
- S’en tenir au strict minimum en matière de tests.
- Solution : procéder à des examens plus fréquents que le strict minimum ; vous réagirez aux menaces plus tôt, avant qu’elles ne soient exploitées.
Exigence DSS 12 – Maintenir une politique régissant les informations de sécurité pour l’ensemble du personnel
A FAIRE :
- Publier une politique de sécurité révisée annuellement, qui documente l’ensemble des appareils et des services critiques du CDE, définisse un accès approprié (en ce qui concerne les rôles, l’usage de cet accès et le lieu) et mette en place une procédure d’évaluation des risques. (12.1, 12.2, 12.3, 12.4)
- Suivre chaque année une formation de sensibilisation à la sécurité avec l’ensemble du personnel qui a accès au CDE. (12.6)
- Affecter aux rôles des responsabilités en termes de documentation des procédures, d’analyse des alertes de sécurité, d’administration des comptes et de surveillance d’accès à toutes les données. (12.5)
- Conserver une documentation sur les prestataires de services. Elle comprendra la liste des services fournis, une sélection avec vérification préalable (y compris avec une évaluation des risques), l’acceptation par le prestataire de services de la responsabilité des CHD et un processus de surveillance de la conformité des fournisseurs à la norme PCI DSS. (12.8.1, 12.8.2, 12.8.3, 12.8.4, 12.8.5)
- Créer un plan d’action, testé annuellement, en cas de violation du système, définissant les missions de chaque rôle, les actions spécifiques aux différentes menaces/alertes, les mesures à prendre pour les systèmes critiques et la sauvegarde des données, les exigences légales en matière de rapports et de notification aux marques de cartes. (12.10)
Ce que l’avenir nous réserve
En fin de compte, la norme PCI DSS 3.2 vous pousse à revoir la culture de votre entreprise. La question de la conformité PCI ne doit pas être abordée uniquement lorsqu’une évaluation est imminente, mais de manière régulière. Repérez vos données sensibles, limitez et surveillez l’accès à celles-ci, mettez en place des alertes en cas de comportement suspect et documentez tout. Non seulement cette checklist vous aidera à vous rapprocher de ces objectifs, mais elle préparera également les cadres pour gérer les nouvelles menaces et les exigences.
Cliquez ici pour afficher une version imprimable de la checklist de la Conformité PCI..
Sources :
http://blog.pcisecuritystandards.org/preparing-for-pci-dss-32
https://www.varonis.com/learn/pci-dss-3-1-it-requirements/
https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss
http://blog.pcisecuritystandards.org/preparing-for-pci-dss-3-2-summary-of-changes
http://info.securitymetrics.com/pci-guide
