Rapport de conformité à la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) - V4.0.1

Le rapport de conformité à la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) aide à évaluer la sécurité de votre application par rapport aux exigences conçues pour protéger les données des titulaires de carte.

À propos de la PCI DSS V4.0.1

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) a été développée pour encourager et améliorer la sécurité des données des titulaires de carte et faciliter l'adoption large de mesures de sécurité des données cohérentes à l'échelle mondiale. La PCI DSS fournit une base de référence des exigences techniques et opérationnelles conçues pour protéger les données des comptes.

La PCI DSS comprend un ensemble minimum d'exigences pour protéger les données des titulaires de carte et peut être renforcée par des contrôles et pratiques supplémentaires pour atténuer davantage les risques, ainsi que par des lois et réglementations locales, régionales et sectorielles. De plus, la législation ou les exigences réglementaires peuvent exiger une protection spécifique des informations personnelles ou d'autres éléments de données (par exemple, le nom du titulaire de la carte). La PCI DSS ne remplace pas les lois locales ou régionales, les réglementations gouvernementales ou d'autres exigences légales.

Les exigences de sécurité de la PCI DSS s'appliquent à tous les composants du système inclus dans ou connectés à l'environnement de données des titulaires de carte (CDE). Le CDE est composé de personnes, de processus et de technologies qui stockent, traitent ou transmettent des données de titulaires de carte ou des données d'authentification sensibles.

"Les composants du système" incluent les dispositifs réseau, les serveurs, les dispositifs informatiques et les applications. Les exemples de composants du système incluent, mais ne sont pas limités à, ce qui suit :

Les systèmes qui fournissent des services de sécurité (par exemple, les serveurs d'authentification), facilitent la segmentation (par exemple, les pare-feu internes), ou pourraient impacter la sécurité du CDE (par exemple, les serveurs de résolution de noms ou de redirection web).
Les composants de virtualisation tels que les machines virtuelles, les commutateurs/routeurs virtuels, les appareils virtuels, les applications/bureaux virtuels, et les hyperviseurs.
Les composants réseau incluant mais ne se limitant pas aux pare-feu, commutateurs, routeurs, points d'accès sans fil, appareils réseau, et autres appareils de sécurité.
Les types de serveurs incluant mais ne se limitant pas aux serveurs web, d'application, de base de données, d'authentification, de messagerie, proxy, de protocole de temps réseau (NTP), et de système de noms de domaine (DNS).
Les applications incluant toutes les applications achetées et personnalisées, y compris les applications internes et externes (par exemple, Internet).
Tout autre composant ou dispositif situé à l'intérieur ou connecté au CDE.

Entités couvertes

La norme PCI DSS s'applique à toutes les entités impliquées dans le traitement des cartes de paiement, y compris les commerçants, les processeurs, les acquéreurs, les émetteurs, et les prestataires de services, ainsi que toutes les autres entités qui stockent, traitent ou transmettent des données de titulaire de carte (CHD) et/ou des données d'authentification sensibles (SAD).

Les exigences PCI DSS s'appliquent aux organisations et environnements où les données de compte (données du titulaire de carte et/ou données d'authentification sensibles) sont stockées, traitées ou transmises. Certaines exigences PCI DSS peuvent également s'appliquer aux organisations qui ont externalisé leurs opérations de paiement ou la gestion de leur CDE. De plus, les organisations qui externalisent leur CDE ou leurs opérations de paiement à des tiers sont responsables de s'assurer que les données de compte sont protégées par le tiers conformément aux exigences PCI DSS applicables.

Pénalités de conformité

Si un commerçant ou un prestataire de services ne se conforme pas aux exigences de sécurité ou ne parvient pas à rectifier un problème de sécurité, les sociétés de cartes peuvent infliger une amende au membre acquéreur ou imposer des restrictions au commerçant ou à son agent.

Conformité requise par

La version 4.0.1 de PCI DSS a remplacé la version 4.0 de PCI DSS et est en vigueur à partir du 1er janvier 2025. La version 4.0 de PCI DSS ne peut pas être utilisée pour la conformité PCI DSS après le 31 décembre 2024.

Régulateurs

Le Conseil des normes de sécurité PCI, et ses membres fondateurs, y compris American Express, Discover Financial Services, JCB, MasterCard Worldwide, et Visa International.

Rapport des vulnérabilités PCI DSS V4.0.1

Le tableau suivant répertorie les exigences spécifiques de PCI DSS V4.0.1 qui sont évaluées. Les vulnérabilités trouvées dans votre application sont associées à ces exigences.

Table 1. Sections de la réglementation
ID	Nom
Exigence 2	Appliquer des configurations sécurisées à tous les composants du système
Exigence 2.2.2	Si le(s) compte(s) par défaut du fournisseur sera(ont) utilisé(s), le mot de passe par défaut est modifié selon l'Exigence 8.3.6. Si le(s) compte(s) par défaut du fournisseur ne sera(ont) pas utilisé(s), le compte est supprimé ou désactivé.
Exigence 2.2.4	Seuls les services, protocoles, démons et fonctions nécessaires sont activés, et toutes les fonctionnalités inutiles sont supprimées ou désactivées.
Exigence 2.2.6	Les paramètres de sécurité du système sont configurés pour prévenir les abus.
Exigence 4	Protéger les données des titulaires de carte avec une cryptographie forte lors de la transmission sur des réseaux publics ouverts
Exigence 5	Protéger tous les systèmes et réseaux contre les logiciels malveillants
Exigence 6	Développer et maintenir des systèmes et des applications sécurisés.
Exigence 6.2.1	Les logiciels sur mesure et personnalisés sont développés de manière sécurisée
Exigence 6.2.4.1	Des techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement logiciel pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités associées dans les logiciels sur mesure et personnalisés, y compris mais sans s'y limiter les attaques par injection, y compris SQL, LDAP, XPath, ou d'autres défauts de commande, de paramètre, d'objet, de faute ou de type d'injection.
Exigence 6.2.4.2	Des techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement logiciel pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités associées dans les logiciels sur mesure et personnalisés, y compris mais sans s'y limiter les attaques sur les données et les structures de données, y compris les tentatives de manipulation des tampons, des pointeurs, des données d'entrée ou des données partagées.
Exigence 6.2.4.3	Des techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement logiciel pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités associées dans les logiciels sur mesure et personnalisés, y compris, mais sans s'y limiter, les attaques sur l'utilisation de la cryptographie, y compris les tentatives d'exploiter des implémentations cryptographiques faibles, non sécurisées ou inappropriées, des algorithmes, des suites de chiffrement ou des modes de fonctionnement.
Exigence 6.2.4.4	Des techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement logiciel pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités associées dans les logiciels sur mesure et personnalisés, y compris, mais sans s'y limiter, les attaques sur la logique métier, y compris les tentatives d'abuser ou de contourner les fonctionnalités et caractéristiques de l'application par la manipulation des API, des protocoles et canaux de communication, des fonctionnalités côté client ou d'autres fonctions et ressources du système/application. Cela inclut le cross-site scripting (XSS) et le cross-site request forgery (CSRF).
Exigence 6.2.4.5	Des techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement logiciel pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités associées dans les logiciels sur mesure et personnalisés, y compris, mais sans s'y limiter, les attaques sur les mécanismes de contrôle d'accès, y compris les tentatives de contourner ou d'abuser des mécanismes d'identification, d'authentification ou d'autorisation, ou les tentatives d'exploiter des faiblesses dans l'implémentation de ces mécanismes.
Exigence 6.3	Les vulnérabilités de sécurité sont identifiées et traitées
Exigence 6.3.2	Un inventaire des logiciels sur mesure et personnalisés, ainsi que des composants logiciels tiers intégrés dans les logiciels sur mesure et personnalisés, est maintenu pour faciliter la gestion des vulnérabilités et des correctifs.
Exigence 6.3.3	Tous les composants du système sont protégés contre les vulnérabilités connues en installant les correctifs/mises à jour de sécurité applicables.
Exigence 6.4	Les applications web accessibles au public sont protégées contre les attaques.
Exigence 6.5.6	Les données de test et les comptes de test sont supprimés des composants du système avant que le système ne soit mis en production.
Exigence 7	Restreindre l'accès aux composants du système et aux données des titulaires de carte selon le besoin professionnel de connaître.
Exigence 7.1	Limiter l'accès aux composants du système et aux données des titulaires de carte uniquement aux personnes dont le travail nécessite un tel accès.
Exigence 7.2.2	L'accès est attribué aux utilisateurs, y compris les utilisateurs privilégiés, en fonction de : la classification et la fonction du poste et des moindres privilèges nécessaires pour accomplir les responsabilités professionnelles.
Exigence 7.2.6	Tout accès utilisateur aux référentiels de données de titulaires de carte stockées est restreint comme suit : via des applications ou d'autres méthodes programmatiques, avec accès et actions autorisées basés sur les rôles des utilisateurs et les moindres privilèges. Seul(s) l'(les) administrateur(s) responsable(s) peut (peuvent) accéder directement ou interroger les référentiels de données de titulaires de carte stockées.
Exigence 8.2.8	Si une session utilisateur est inactive pendant plus de 15 minutes, l'utilisateur doit se réauthentifier pour réactiver le terminal ou la session.
Exigence 8.3.1	Tous les accès utilisateur aux composants du système pour les utilisateurs et les administrateurs sont authentifiés via au moins un des facteurs d'authentification suivants : Quelque chose que vous savez, comme un mot de passe ou une phrase secrète. Quelque chose que vous avez, comme un dispositif de jeton ou une carte à puce. Quelque chose que vous êtes, comme un élément biométrique
Exigence 8.3.2	Une cryptographie forte est utilisée pour rendre tous les facteurs d'authentification illisibles lors de la transmission et du stockage sur tous les composants du système.
Exigence 8.6.2	Les mots de passe/phrases secrètes pour toute application et comptes système pouvant être utilisés pour une connexion interactive ne sont pas codés en dur dans les scripts, les fichiers de configuration/propriété, ou le code source sur mesure et personnalisé.
Exigence 11.4	Des tests de pénétration externes et internes sont régulièrement effectués, et les vulnérabilités exploitables et les faiblesses de sécurité sont corrigées.