Les 12 exigences PCI DSS

Les pares-feux contrôlent la transmission de données entre le réseau interne d’une entreprise et les réseaux externes non approuvés, ainsi que le trafic dans des zones plus sensibles du réseau interne approuvé. L’exigence 1 PCI DSS requière de la part des systèmes qu’ils utilisent des pares-feux afin d’empêcher des accès non-autorisés. Lorsque d’autres éléments du système fournissent la fonctionnalité de pare-feu, ils doivent également être compris dans le champ d’application et l’évaluation de cette condition.

Les paramètres de sécurité par défaut de nombreux systèmes très utilisés sont connus, facilement exploitables et souvent utilisés par les communautés de pirates afin de compromettre ces systèmes. Les paramètres par défaut définis par les fournisseurs doivent donc être changés et les comptes par défaut non utilisés désactivés ou supprimés avant que le système ne soit installé sur un réseau. Cela concerne également tous les mots de passe par défaut, sans exception. Si les pares-feux sont mis en place correctement, selon l’exigence 1, ils doivent également être conformes à l’exigence 2.

Le stockage de données de titulaires de carte doit être gardé à un niveau minimum et des politiques, procédures et processus de conservation et d’élimination des données doivent être mis en place. Certaines données – telles que le contenu de la puce ou de la piste magnétique, la code de vérification de la carte (CVN) ou le numéro d’identification personnel (PIN) – ne doivent jamais être conservées. Le cryptage, la troncature, le masquage et le hachage sont des composants stratégiques de la protection des données de titulaires de carte. Sans accès aux clés cryptographiques appropriées, les données seront illisibles et inutilisables par le pirate, même s’il parvient à contourner les autres contrôles de sécurité. Les clés cryptographiques doivent donc être conservées de manière sécurisée et leur accès doit être limité aux quelques dépositaires nécessaires. D’autres méthodes de protection des données doivent également être prises en compte.

Une cryptographie robuste ainsi que des protocoles de sécurité (ex . TLS, IPSEC, SSH, etc.) doivent être utilisés afin de garantir la sécurité des données sensibles des titulaires de carte durant leur transmission vers des réseaux publics, ouverts pouvant être facilement accessibles pour des individus mal intentionnés. Exemples de réseaux ouverts, publics : Internet, technologies sans fil (ex. Bluetooth), General Packet Radio Service (GPRS) et les communications satellites. Les bonnes pratiques de l’industrie doivent être suivies afin de mettre en place un cryptage robuste pour l’authentification et la transmission. Les politiques et procédures de sécurité pour le cryptage de transmission de données de titulaires de carte soit être documenté et être connu de toutes les parties concernées.

Des logiciels anti-virus, capables de détecter, de supprimer ou des protéger contre tout type de logiciels malveillants (ex. virus, worms, Trojans) doivent être utilisés sur tous les systèmes fréquemment affectés par des logiciels malveillants afin de les protéger contre ces menaces. Pour les systèmes n’étant pas couramment affectés par des logiciels malveillants, l’évolution des menaces doit être ré-évaluée régulièrement afin de déterminer si la mise en place d’un logiciel anti-virus est nécessaire. Les mécanismes anti-virus doivent être maintenus et actifs et ne doivent être désactivés que si cela a été autorisé de manière formelle et à des fins spécifiques.

De nombreuses vulnérabilités de sécurité sont résolues par des correctifs développés par les fournisseurs de logiciels. Les organisations doivent donc mettre en place un processus d’identification des vulnérabilités de sécurité et les classer selon le niveau de risque, elles doivent ensuite installer les correctifs nécessaires sous un délai d’un mois suivant leur publication afin de protéger les données des titulaires de carte. Toutes les applications logicielles, qu’elles soient développées en interne ou en externe, doivent être développées de manière sécurisée selon la norme PCI DSS, basées sur les normes et/ou bonnes pratiques de l’industrie et doivent prendre en compte la sécurité de l’information tout au long de leur cycle de développement.

Utiliser les comptes autorisés et abuser des privilèges utilisateurs est l’un des moyens les plus simples pour les pirates d’obtenir l’accès à un système. Il s’agit également du type d’attaque le plus difficile à détecter. Les systèmes et processus doivent donc être documentés afin de limiter les droits d’accès aux données sensibles aux seules personnes en ayant la nécessité et selon les rôles et responsabilités clairement définis au préalable. Autrement dit, l’accès est restreint aux seuls individus qui ont une raison professionnelle légitime.

La capacité à identifier un utilisateur unique permet d’assurer que l’accès au système est limité aux personnes ayant l’autorisation nécessaire. Cela permet également d’établir une piste d’audit pouvant être analysée suite à un incident. Des politiques et procédures documentées doivent être mises en place afin d’assurer une bonne gestion d’identification des utilisateurs pour les utilisateurs non-finaux et les administrateurs sur les éléments de tous les systèmes. Chaque utilisateur doit se voir attribué un identifiant unique qui doit être géré selon des directives spécifiques. Une gestion contrôlée de l’authentification utilisateur (ex. Utilisation des mots de passe, biométrie, cartes à puce) doit également être utilisée et, puisque trois-quarts des intrusions réseau exploitent un mot de passe faible ou volé, une authentification à deux facteurs doit être utilisée pour tout accès au réseau à distance.

Les violations de données électroniques ne sont pas la seule source de perte de données, l’accès physique aux systèmes doit également être limitée et contrôlée via les contrôles appropriés. Les procédures doivent être mises en place afin de distinguer le personnel et les visiteurs sur-site et l’accès aux zones sensibles (ex. salles de serveurs, datacenters, etc.) doit être limité en conséquence. Tout média doit être sécurisé et sont rangement, son accès et sa distribution contrôlés. Les médias doivent être détruits de manière spécifique lorsqu’ils ne sont plus nécessaires. Les appareils saisissant les données de cartes de paiement via interaction physique directe avec la carte doivent être protégés contre toute altération, substitution et doivent être inspectés périodiquement afin de détecter toute altération ou substitution. Une liste des appareils doit être maintenue à jour.

L’utilisation de mécanismes de journalisation est essentielle afin de prévenir, de détecter et de minimiser l’impact d’une altération de données. En l’absence de journaux retraçant les activités du système, il est très difficile, sinon impossible, de déterminer la cause d’un incident. Des traces d’audit sécurisées et contrôlées doivent être mises en place afin de lier tout accès aux éléments du système à un utilisateur unique et à leurs activités (y compris l’accès aux données de titulaires de carte, les actions d’individus ayant un accès privilégié, l’accès aux traces d’audit, les tentatives d’accès non-valides, l’utilisation et les modifications des mécanismes d’identification et d’authentification, l’initialisation, l’arrêt ou la pause de journaux d’audit et le création ou la suppression d’objets au niveau du système). L’historique d’audit doit être conservé pendant au moins un an, avec un minimum de trois mois de journaux disponibles immédiatement pour analyse. Les journaux et les évènements de sécurité doivent être révisés régulièrement afin d’identifier des activités anormales ou suspicieuses.

De nouvelles vulnérabilités sont régulièrement découvertes et exploitées. Il est donc essentiel de tester les composants de système, les processus et les logiciels personnels de manière régulière afin de s’assurer que les contrôles de sécurité reflètent toujours les nouveaux environnements. La documentation des processus doit être mise en place de façon trimestrielle afin de détecter et d’identifier tout point d’accès sans-fil non autorisé. Des scans de réseau internes et externes doivent être effectués par un personnel qualifié une fois par trimestre et suite à tout changement significatif du réseau (ex. installation de nouveaux éléments dans le système, changement de typologie du réseau, modification des règles de pare-feu et mises à jour produits) Les techniques de détection/prévention des intrusions doivent être utilisées afin de détecter et/ou prévenir les intrusions réseau et un mécanisme de détection de changement doit être utilisé afin d’effectuer une comparaison hebdomadaire des fichiers et d’alerter le personnel en cas de modification non-autorisée du système.

Note : La condition 11.3 a été mise à jour dans la dernière version PCI DSS. Après le 30 juin 2015, les tests d’intrusion internes et externes doivent être menés au moins une fois par an ainsi que suite à tout changement significatif sur le réseau (ex. mise à jour du système d’exploitation, l’ajout de sous-réseaux ou de serveur web). Les vulnérabilités exploitables découvertes durant le test d’intrusion doivent être corrigées et un test doit ensuite être répété afin de confirmer que la correction est adéquate. Avant le 30 juin 2015, il s’agissait d’une bonne pratique à suivre mais qui n’était pas requise.

Afin de se conformer au PCI DSS, les organisations doivent établir, publier, maintenir et diffuser une politique de sécurité, qui devra être révisée au moins une fois par an et mise à jour selon les risques liés à l’environnement. Un processus d’évaluation des risques doit être mis en place afin d’identifier les menaces et les faiblesses, des politiques d’usage doivent être développées pour les technologies critiques, les responsabilités de sécurité doivent être clairement définies pour tout le personnel et un programme formel de sensibilisation du personnel doit être mis en place. Les organisations doivent également mettre en place un plan de réponse aux incidents afin d’être en mesure de répondre immédiatement en cas de faille du système.