Norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) - Rapport de conformité V4

Ce rapport indique les problèmes PCI trouvés sur votre site. Beaucoup de vulnérabilités des applications web peuvent conduire à des violations de sécurité directes ou indirectes concernant les informations personnelles, susceptibles d'être considérées comme des infractions à ces réglementations.

Pourquoi est-ce important

La norme PCI sur la sécurité des données propose une approche unifiée de la protection des données confidentielles pour toutes les marques de cartes. Cette norme résulte de la collaboration entre Visa et MasterCard et est conçue pour créer des exigences de sécurité communes pour l'industrie. D'autres sociétés de cartes de crédit implantées aux Etats-Unis (par exemple, American Express®, Discover, JCB et Diners) ont également adopté la norme PCI sur la sécurité des données pour leurs programmes respectifs. La norme PCI est destinée à protéger les données du détenteur de carte, où qu'il réside, et de garantir que les membres, commerçants et fournisseurs de services appliquent des normes de sécurité élevées aux informations.

Vulnérabilités PCI DSS

ID	Nom
Exigence 2	Appliquez des configurations sécurisées à tous les composants du système.
Exigence 2.2.2	Si le ou les comptes par défaut du fournisseur sont utilisés, le mot de passe par défaut est modifié conformément à l'exigence 8.3.6. Si le ou les comptes par défaut du fournisseur ne sont 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 empêcher toute utilisation abusive.
Exigence 4	Protégez les données des titulaires de carte grâce à une cryptographie robuste lors de leur transmission sur des réseaux publics ouverts.
Exigence 5	Protégez 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 en toute sécurité.
Exigence 6.2.4.1	Les techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement de logiciels 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, notamment SQL, LDAP, XPath ou autres commandes. défauts de paramètre, d’objet, de défaut ou de type injection.
Exigence 6.2.4.2	Les techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement de logiciels 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 contre les données et les structures de données, y compris les tentatives de manipulation des tampons, des pointeurs. , données d'entrée ou données partagées.
Exigence 6.2.4.3	Les techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement de logiciels 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 contre l'utilisation de la cryptographie, y compris les tentatives d'exploitation de logiciels faibles, non sécurisés ou implémentations cryptographiques, algorithmes, suites de chiffrement ou modes de fonctionnement inappropriés.
Exigence 6.2.4.4	Les techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement de logiciels 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 contre la logique métier, y compris les tentatives d'abus ou de contournement des fonctionnalités de l'application et fonctionnalités via la manipulation d’API, de protocoles et de canaux de communication, de fonctionnalités côté client ou d’autres fonctions et ressources système/application. Cela inclut les scripts intersites (XSS) et la falsification de requêtes intersites (CSRF).
Exigence 6.2.4.5	Les techniques d'ingénierie logicielle ou d'autres méthodes sont définies et utilisées par le personnel de développement de logiciels 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 contre les mécanismes de contrôle d'accès, y compris les tentatives de contournement ou d'abus d'identification, des mécanismes d’authentification ou d’autorisation, ou des tentatives d’exploitation des faiblesses dans la mise en œuvre de tels mécanismes.
Exigence 6.3	Les vulnérabilités de sécurité sont identifiées et corrigées.
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 publiques 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 passe en production.
Exigence 7	Restreindre l’accès aux composants du système et aux données des titulaires de carte en fonction des besoins de l’entreprise.
Exigence 7.1	Limitez l’accès aux composants du système et aux données des titulaires de carte aux seules personnes dont le travail nécessite un tel accès.
Exigence 7.2.2	L'accès est attribué aux utilisateurs, y compris aux utilisateurs privilégiés, en fonction de : La classification et la fonction du poste et les moindres privilèges nécessaires pour exercer les responsabilités professionnelles.
Exigence 7.2.6	Tous les accès des utilisateurs aux référentiels de requêtes de données de titulaires de cartes stockées sont restreints comme suit : Via des applications ou d'autres méthodes programmatiques, avec un accès et des actions autorisées en fonction des rôles d'utilisateur et des moindres privilèges. Seuls les administrateurs responsables peuvent accéder directement aux référentiels de CHD stockés ou les interroger.
Exigence 8.2.8	Si une session utilisateur est restée 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 des utilisateurs et des administrateurs aux composants du système sont authentifiés via au moins l'un des facteurs d'authentification suivants : Quelque chose que vous connaissez, comme un mot de passe ou une phrase secrète. Quelque chose que vous possédez, comme un périphérique à 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 pendant la transmission et le stockage sur tous les composants du système.
Exigence 8.6.2	Les mots de passe/phrases secrètes de toutes les applications et comptes système pouvant être utilisés pour la connexion interactive ne sont pas codés en dur dans les scripts, les fichiers de configuration/propriétés ou le code source sur mesure et personnalisé.
Exigence 11.4	Des tests d'intrusion externes et internes sont régulièrement effectués et les vulnérabilités exploitables et les faiblesses de sécurité sont corrigées.