> Tech > PCI DSS dans le détail

PCI DSS dans le détail

Tech - Par Renaud ROSSET - Publié le 29 avril 2013
email

A l'origine du standard PCI DSS on trouve un consortium d'organismes de cartes de crédit : American Express, Discover Card, JCB International (un important émetteur de cartes de crédit non-U.S. présent dans plus de 15 pays, fondé en 1961 sous le nom de Japan Credit Bureau), MasterCard, et Visa.

PCI DSS dans le détail

La version actuelle de PCI DSS, 1.2, est en vigueur depuis octobre 2008. Chaque DSS a un cycle de vie de 24 mois ; par conséquent, il y aura une révision ou une nouvelle version début octobre 2010. La date-butoir de conformité PCI DSS est passée, et donc toute installation qui utilise et accepte des cartes de crédit devrait déjà être en conformité. Cependant, les institutions financières—les banques que les marchands utilisent pour gérer les dépôts de cartes de crédit—sont le bras armé de PCI DSS, et beaucoup d’entre elles sont en retard pour la vérification de la conformité PCI parmi leurs clients.

PCI DSS

Il faut bien comprendre que le cryptage, quoique très important dans PCI, n’est qu’un des six jalons qui constituent la conformité PCI DSS globale. Chaque jalon est divisé en une ou plusieurs exigences. Voyons ces six jalons :

1.    Bâtir et maintenir un réseau sûr
2.    Protéger les données du détenteur de la carte
3.    Maintenir un programme de gestion des vulnérabilités
4.    Appliquer de strictes mesures de contrôle d’accès
5.    Superviser et tester régulièrement les réseaux
6.    Maintenir une stratégie de sécurité de l’information

Il existe quatre niveaux de conformité PCI, selon le volume de transactions par cartes de crédit par an d’une société.

Tout d’abord, une société doit déterminer dans quel niveau elle se trouve. Plus le niveau est élevé et plus les exigences de conformité sont fortes. Par exemple, une société qui traite plus de 6 millions de transactions par cartes de crédit chaque année se situera au niveau 1. Cela se traduira par des analyses trimestrielles du réseau, des audits annuels par une firme extérieure, le test régulier des pare-feu et autres mesures de vigilance. Une société de niveau 4, c’est-à-dire avec moins de 20 000 transactions de e-commerce ou un million de transactions par cartes de crédit n’a besoin que d’une « autoévaluation » annuelle par un membre du personnel autorisé, et d’analyses trimestrielles des interfaces de paiement sur Internet, mais les résultats n’ont pas à être publiés. Une simple « attestation de conformité » est signée par le responsable du marchand et rangée en lieu sûr dans l’entreprise et/ou remise à l’institution financière du marchand.

Il est important de préciser que, bien que PCI ait mis en place ces niveaux, chacune des marques de paiement a sa propre version qui supplante PCI. Bien que ces programmes individuels ressemblent beaucoup aux standards PCI, il convient de les passer en revue.

Voici leurs noms :

•    American Express :Data Security Operating Policy, ou DSOP
•    Discover Card : Discover Information Security & Compliance, ou DISC
•    JCB : Data Security Program
•    MasterCard : Site Data Protection Program, ou SDP
•    Visa : Cardholder Information Security Program, ou CISP

Chaque jalon PCI DSS indique plusieurs exigences connexes, comme la protection du réseau par des pare-feu et la détection d’intrusion (IDS, intention detection system). Le jalon n’est considéré complet qu’une fois toutes les exigences satisfaites. Quand les six jalons ont été complètement honorés, la conformité PCI est reconnue.  Quand la première version des règles a été publiée, beaucoup de départements IT ont éprouvé des difficultés pour gérer chaque tâche conduisant à la conformité. Avec la dernière version, 1.2, PCI a publié une « Prioritized Approach, » (approche par priorités). C’est simplement un tableur où les tâches sont groupées logiquement pour parvenir au plus vite à la conformité. La documentation PCI DSS donne des directives générales plutôt que des règles pures et dures. Cette approche peut sembler un peu vague, mais elle est logique de la part de PCI, parce qu’il n’y a pas deux environnements exactement identiques.

Voici un aperçu des exigences pour chaque jalon.

Bâtir et maintenir un réseau sûr.

Ce jalon concerne l’infrastructure physique. En voici les étapes :

1.    Configurer correctement les pare-feu, documenter tout le réseau en incluant les points d’accès et les utilisateurs sans fil, identifier le rôle de chaque serveur du réseau, et verrouiller l’accès aux fichiers et aux dossiers contenant les données de cartes de crédit.

2.    Changer les mots de passe par défaut, définir les valeurs de sécurité système, utiliser des conventions de nommage d’unités homogènes, désactiver toutes les fonctions IP non nécessaires, et instaurer des connexions sûres avec les serveurs Web.

Protéger les données du détenteur de la carte.

On se concentre ici sur le cryptage des données et au-delà. Ici, il convient de définir ce que sont des données « au repos ». Certaines données peuvent être décryptées et gardées dans des variables de programmes – en mémoire – seulement quand c’est nécessaire. On dit alors que ces données sont « au repos », c’est-à-dire quand elles sont sur le disque dans un état inactif. Ce jalon est le plus long parce qu’il traite du cryptage.

1.    Quand des données de cartes sont stockées, il faut en garder le minimum et juste le temps qu’il faut pour effectuer une transaction. Il n’est pas question de stocker sur le système, en un point quelconque, la vérification de valeur de carte (card verification value, CVV). C’est le nombre de trois ou quatre chiffres imprimé au dos d’une carte de crédit. Il garantit que la carte est légitime, parce qu’il faut être en sa possession pour lire le nombre. Si vous avez besoin de cette valeur à des fins d’autorisation, il ne faut pas la capturer. Tout numéro d’identification (PIN) qui doit être composé ne doit pas non plus être stocké. Quand une carte de crédit est affichée, elle doit être masquée, mais il est tout à fait admis d’afficher les six premiers chiffres et les quatre derniers dans un but de vérification.

2.    Les clés de cryptage doivent être protégées contre la divulgation et l’utilisation frauduleuse, et leur accès doit être le plus réduit possible. Les clés gérées doivent être puissantes et stockées en toute sécurité. Elles doivent faire l’objet d’une rotation régulière et doivent être créées par plusieurs auteurs de façon segmentée et cloisonnée. Les utilisateurs autorisés qui créent tout ou partie de la clé doivent signer une déclaration indiquant qu’ils comprennent et acceptent ces responsabilités.

3.    Lors de la rotation des clés, si une base de données a été conçue pour utiliser un fichier externe (un pour chaque champ crypté), la rotation doit pouvoir s’effectuer pendant la production, sans être obligé de verrouiller ces fichiers. Le processus se déroule ainsi : dans le fichier externe, le numéro de clé qui a servi à crypter les valeurs est stocké dans chaque enregistrement. Quand une rotation de clé est nécessaire, un processus d’arrière-plan peut être chargé de lire chaque enregistrement, un à un, de décrypter la valeur avec la clé originale, puis de recrypter avec la nouvelle clé et mettre à jour l’enregistrement.

4.    Quand des fichiers doivent être transmis, soit les champs sensibles doivent être cryptés, soit tout le fichier doit être crypté si aucun champ sensible ne l’est. S’il faut envoyer du texte en clair sur une ligne sécurisée, la bonne solution consiste à décrypter le fichier ou ses données dans la bibliothèque QTEMP, parce que la bibliothèque et son contenu sont supprimés au terme de chaque job. S’il y a une connexion sans fil,  WEP (Wired Equivalent Privacy) ne peut pas être utilisé depuis le 30 juin 2010 pour les installations sans fil existantes. Pour une nouvelle installation, WEP n’est pas du tout autorisé. Vous vous tournerez alors vers les meilleurs standards du marché, comme IEEE 802.11.

5.    N’envoyez jamais de données en clair sensibles ou confidentielles dans un e-mail, un message instantané, ou une session de chat.

Maintenir un programme de gestion des vulnérabilités.

Ce jalon s’intéresse à la protection antivirus et au barrage contre les logiciels malveillants (malware).

1.    Tous les systèmes qui vérifient normalement la présence de malware doivent être maintenus actifs avec des définitions actualisées en permanence.

2.    Tout code de traitement d’erreurs doit être rigoureusement testé avant de servir en production. Dans ma société, nous avons dû changer une fonction de nos programmes de cryptage : la possibilité de générer un dump formaté en cas d’erreur exceptionnelle. Les valeurs courantes de toutes les variables, par défaut, apparaissent dans un dump formaté. Il faut supprimer cela pour éviter que la variable contenant la clé ne s’affiche.

3.    Tous les systèmes doivent être protégés contre toute forme d’injection et d’exécution de fichiers malveillants.

Appliquer de strictes mesures de contrôle d’accès.

1.    Ayez une valeur par défaut « deny-all’ (refus général), et n’autorisez que les utilisateurs auxquels la direction permet de voir toutes les données en clair. Maintenir une table des utilisateurs autorisés. Un responsable doit signer pour valider chaque utilisateur autorisé. Même quand un utilisateur a le droit de voir du texte en clair, une touche de fonction séparée doit être actionnée le moment venu. Cette action supplémentaire est nécessaire parce que d’autres utilisateurs non autorisés pourraient voir à tout moment l’écran de l’utilisateur autorisé.

2.    Passez en revue tous les programmes dans lesquels des utilisateurs autorisés peuvent voir des données en clair.

3.    Chaque utilisateur doit avoir un ID utilisateur unique. Les nouveaux utilisateurs devront changer leur mot de passe après la première utilisation de leur profil. Quand des utilisateurs quittent la société, désactivez immédiatement leur accès.

4.    Désactivez les comptes inactifs (depuis plus de 90 jours).

5.    Faites tourner les mots de passe au moins tous les 90 jours, et exigez au moins sept caractères. Pour ces environnements, songez à utiliser Kerberos (single sign-on, SSO) pour soulager un peu les utilisateurs et faciliter le contrôle de l’administration.

6.    Les sessions inactives doivent se terminer automatiquement après 30 minutes.

7.    Restreignez l’accès physique aux données et surveillez l’accès à l’aide de caméras.

8.    Instaurez une procédure permettant à tous les employés de reconnaître facilement un non-employé. Exigez de tous les visiteurs qu’ils rendent leur badge en partant.
9.    Les médias doivent être stockés en dehors du site, en un lieu sécurisé.

10.    Ne conservez les médias de sauvegarde qu’aussi longtemps que nécessaire.

Superviser et tester régulièrement les réseaux.

Tous les accès utilisateur doivent être journalisés, de même que toutes les actions des utilisateurs puissants. Les journaux d’audit eux-mêmes ne doivent pas être accessibles aux utilisateurs. Il faut prévoir des analyses de réseau trimestrielles par une firme d’audit extérieur.

1.    La pénétration du système doit être testée au moins une fois par an, où chaque fois qu’un nouveau système d’exploitation est installé.

2.    Il faut vérifier l’intégrité des fichiers pour détecter des modifications non autorisées.

Maintenir une stratégie de sécurité de l’information.

Il faut expliquer clairement à chaque employé ce que l’on attend de lui en matière de protection et de non-exposition des données sensibles.

1.    La liste des utilisateurs autorisés doit être tenue et actualisée en permanence, avec leur niveau d’accès.

2.    L’accès aux données doit être supervisé régulièrement.

3.    Les employés doivent reconnaître qu’ils ont lu et compris les règles et procédures de la société en matière de sécurité.

Téléchargez cette ressource

Livre blanc Sécurité et Stockage des documents

Livre blanc Sécurité et Stockage des documents

Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.

Tech - Par Renaud ROSSET - Publié le 29 avril 2013