PCIDSS 3.0 Tips and Traps

par Jessica Gallante et Nathalie Planteur

Disclaimer : Nous ne sommes pas QSA et cet article ne reflète aucunement les opinions de notre employeur et patati et patatrap. Nous avons composé cet article à 4 mains dans le seul objectif d'animer la #PCIDSS avec un peu de #HipHop car "qui prétend faire de la PCIDSS sans prendre position ?".

Respecter le standard PCIDSS exige une certaine agilité d'esprit ou un certain aveuglement. Vous pouvez ainsi choisir d'être purement "conforme" (donc pas Business As Usual) ou bien de respecter l'esprit de la norme pour améliorer progressivement l'ensemble des mécanismes organisationnels et techniques concourant au maintien en conditions de sécurité optimales de votre Système d'Information (si vous bondissez déjà en lisant ces quelques lignes c'est que vous avez déjà choisi votre camp ou que - QSA ou auditeur 27x - vous aiguisez vos plus belles lames pour pourfendre ...).

Bref, il est souvent reproché (et nous sommes les premières à en faire partie) au standard de ne pas inclure tel ou tel éclaircissement, telle ou telle exigence ... Véritablement, ceci ne pose problème que si vous vous concentrez exclusivement sur une stricte conformité (avec des coûts réduits au maximum tout en conservant une conformité fil du rasoir) sans réfléchir aux meilleurs moyens de protéger les données cartes que votre Système d'Information transporte, traite et stocke.

Deux points essentiels sont ainsi à garder en tête selon nous :

• N'oubliez pas que le standard vise à protéger les données cartes (nous utilisons cette expression par facilité pour regrouper CHD et SAD) et n'a aucunement pour objectif de protéger vos fichiers clients/patients ou les ordinateurs portables de votre Direction Commerciale ou de votre Directeur Général.

• Travaillez avec votre QSA et (surtout) pas contre lui. Tous les QSA que nous avons eu la chance de rencontrer étaient des professionnels du standard et de ses pièges et tous étaient experts dans un domaine organisationnel et/ou technique précis. Profitez donc de leur expérience pour échanger et construire votre conformité et ne visez pas un simple tampon sur votre futur ROC.

Nous sommes intimement convaincues (et donc peut être partiales dans notre discours) que l'application du standard représente un _plus_ fondamental dans le dispositif de contrôle des établissements concernés : il est ainsi nécessaire d'évaluer périodiquement les risques, de maintenir un niveau de sécurité organisationnels et technique optimal pour se prémunir de ces risques, d'organiser et tracer tous les changements organisationnels et techniques des environnements concernés, de surveiller les pistes d'audit et les évènements anormaux se produisant, de sensibiliser les collaborateurs, etc. Retenez néanmoins que tout ceci ne doit jamais être bloquant pour votre business (hors non conformité flagrante bien entendu).

Deux autres critères à retenir sont donc selon nous :

• N'alourdissez pas outre mesure votre organisation de process fonctionnels : il est tout à fait possible de respecter l'esprit de la norme sans allonger drastiquement les délais de recette et passage en production ou augmenter significativement les coûts de fonctionnement de votre Direction Informatique.

• Choisissez finement qui sera votre responsable de la conformité PCIDSS et préférez de prime abord un collaborateur ouvert et apprécié de l'ensemble des lignes métier et support de votre organisation. Une expérience en tant qu'auditeur sera évidement un plus non négligeable (pour reconnaitre les questions pièges quand celles-ci se présentent). Notre conseil à nous ? Choisissez quelqu'un de #HipHop, c'est déjà c#%}^Wcompliqué d'appliquer la norme, autant le faire dans la bonne humeur.

Après tous ces entrechats (sont là) et issus de notre propre expérience terrain des deux dernières années passées à voir et revoir (et revoir ... et revoir ... au revoir) divers environnements PCIDSS chez divers clients, nous vous proposons une liste choisie de "Tips and Traps" à parcourir et cocher entre amis. Pour les connaisseurs ou vous qui nous lisez (écrivez) sur Twitter, vous aurez certainement le sourire aux lèvres en pensant aux âpres débats et négociations en interne ou avec vos QSA et pour ceux qui nous découvrent et qui souhaitent échanger, n'hésitez pas à nous contacter.

Jess (@JessicaGallante) et Nath (@NathPlanteur)

PS : Un grand merci à @helpacsoout qui nous a suggéré d'écrire cet article après nos échanges sur Twitter et à @AdBaz1 pour la relecture.

PPS : "We #PCIDSS-ize either for #Compliance or for #Infosec. Looking for compliance only? theres a lot that PCIDSS cant fix".

Build and Maintain a Secure Network and Systems

Le premier ensemble d'exigences ("1. Install and maintain a firewall configuration to protect cardholder data" et "2. Do not use vendor-supplied defaults for system passwords and other security parameters") présente bien les trois problématiques qui sont pour nous caractéristiques de la démarche à mettre en oeuvre.

• La connaissance (et la justification) de votre périmètre PCIDSS : l'exigence #2.4 impose de maintenir un référentiel/inventaire de tous les composants considérés comme in-scope, ceci vaut donc pour tous les composants applicatifs, système et réseau composant le CDE mais également pour tous les composants annexes - qui ne sont ni dans le CDE ni en frontière de celui-ci) donc la réduction du niveau de sécurité ou la compromission peut affaiblir ou permettre de compromettre un composant typé CDE. La difficulté résidant dans la pérennisation de ce référentiel au gré des évolutions fonctionnelles et techniques impactant le Système d'Information.

• Le respect de l'esprit de la norme et non la juste conformité à celle-ci : l'exigence #1.1.3 implique de représenter les flux de données concernant les données cartes sous forme de diagrammes (?) pour les aspects réseau et système. Ces diagrammes ne doivent pas être simplement formalisés juste avant l'audit pour être conforme, ils doivent servir de base de travail aux diverses exigences imposées par le standard (évolution des analyses de risques en fonction des besoins métier, mises à jour des systèmes et réseau au gré des évolutions imposées par le Schéma Directeur Informatique, etc.).

• La sujétion de la norme PCIDSS à la législation ou à la règlementation locale : l'exigence #1.4 requiert l'installation de pare-feu personnels sur les ordinateurs personnels (et mobiles etc.) des collaborateurs si ceux-ci sont à la fois utilisés au sein et en dehors du Système d'Information. La problématique qui se pose alors concerne l'application de règles propres à l'entreprise sur les dispositifs numériques personnels des employés.

Protect Cardholder Data

Le second ensemble d'exigences ("3. Protect stored cardholder data" et "4. Encrypt transmission of cardholder data across open, public networks") illustre trois autres challenges qu'il convient d'appréhender.

• Bien mesurer que tous les processus de contrôle doivent faire l'objet de pistes d'audits, de traces, de comptes rendus archivés et conservés pour présentation au QSA : l'exigence #3.1 impose ainsi de conserver les comptes rendus d'analyse trimestrielle de rétention des données cartes après expiration et ce même si vous savez pertinemment qu'aucune donnée carte conservée par devers vous n'a excédé la période maximale pour laquelle vous êtes autorisés à les conserver.

• Bien comprendre que tous les processus de segmentation imposés par le standard ont pour objectif de durcir au maximum les données cartes transportées, traitées ou stockées : l'exigence #3.4 exprime clairement qu'il est trivial de reconstruire les PAN lorsque l'on dispose à la fois de la version tronquée et hachée d'un même enregistrement.

• Bien comprendre que les interdictions imposées par la norme doivent évidement être observées en compromis des besoins métier : l'exigence #4.2 précise ainsi qu'il est interdit de transmettre des PAN en clair par messagerie instantanée sauf si les PAN sont rendus illisibles ou sont sécurisés par des moyens cryptographiquement robustes.    

Maintain a Vulnerability Management Program

Le troisième ensemble d'exigences ("5. Protect all systems against malware and regularly update anti-virus software or programs" et "6. Develop and maintain secure systems and applications") expose un certain nombre d'impératifs techniques à respecter qui peuvent amener à des non conformités pourtant facilement évitables pour autant qu'un processus organisationnel de gestion des vulnérabilités soit convenablement implémenté et respecté :

• Contrairement aux idées reçues, le standard impose par exemple avec l'exigence #5.1.2 qu'une évaluation périodique soit menée pour justifier que les systèmes *Nix ne sont pas affectés par des "malicious software" : cette évaluation périodique doit donc être documentée.

• La conservation des journaux afférents aux mécanismes antiviraux imposée par l'exigence #5.2 précise un respect de l'exigence #10.7 mais la guidance correspondante correspond à l'exigence #10 dans son ensemble : il est donc recommandé de mener une analyse précise sur ce sujet.

• L'application des correctifs qualifiés comme critiques doit être réalisée sous 30 jours tel qu'imposé par l'exigence #6.2 mais la guidance correspondante précise bien que les correctifs qualifiés avec des niveaux de sévérité inférieurs doivent être installés sous 2 à 3 mois.

• La mise en œuvre de processus de revue de code tel qu'imposée par l'exigence #6.3.2 nécessite évidement documentation et trace mais également une validation des résultats par le management (les comptes rendus ou procès-verbaux de ces validations pouvant évidement être demandés par le QSA).

• La mise en œuvre du processus de contrôle des changements nécessite pour l'exigence #6.4.5 une documentation spécifique aux correctifs de sécurité avec à minima une description de l'impact, une approbation formelle et un mécanisme de retour arrière.

• La formation continue des développeurs aux bonnes pratiques en matière de développement sécurisé doit être documentée et, conformément à l'exigence #6.5c, n'oubliez pas que le QSA interviewera un panel représentatif de développeurs à ce sujet (par exemple pour leurs demander comment ils assurent un traitement sécurisé des données sensibles en mémoire).

• La revue périodique du niveau de vulnérabilités des applications web publiées sur Internet imposée par l'exigence #6.6 en cas d'absence de dispositif de type WAF doit être réalisée au moins annuellement mais également après chaque changement.

Implement Strong Access Control Measures

Le quatrième ensemble d'exigences ("7. Restrict access to cardholder data by business need to know", "8. Identify and authenticate access to system components" et "9. Restrict physical access to cardholder data") présente de nombreux cas concrets de questions qui pourront être (seront) posées par votre QSA et pour lesquels des non conformités sont également facilement évitables.

• L'exigence #7.1.3 requiert que les accès soient fournis selon la fiche de poste (ou classification du poste) et la fonction du collaborateur concerné. N'ayez aucun doute sur le fait que votre QSA souhaitera consulter cette classification des rôles et postes en vigueur et qu'il interviewera par échantillonnage un certain nombre de collaborateurs sur ce sujet précis.

• La réactivation des comptes verrouillés par un service Helpdesk ou administrateur nécessite, selon l'exigence #8.1.7, que l'utilisateur demandant cette réactivation soit formellement identifié/validé avant déverrouillage. A l'identique, il est fort probable que votre QSA vous demande comment vous vérifiez l'identité de l'utilisateur demandant une réinitialisation de son mot de passe tel qu'imposé par l'exigence #8.2.2.

• L'exigence #8.4 précise que votre QSA interviewera un panel d'utilisateurs et consultera la documentation afférente à votre politique d'authentification pour s'assurer que les utilisateurs disposent de conseils avisés sur les moyens mis à leur disposition pour protéger leur identifiants et mots de passe de connexion au Système d'Information.

• L'exigence #8.6 précise que les mécanismes d'authentification forte déployés ne peuvent être partagés entre multiples utilisateurs logiques ou physiques et il est donc fort probable que votre QSA procède à des recoupements à des périodes données sur la base des journaux que vous devez avoir conservés. (Exemples types : deux administrateurs connectés simultanément en astreinte alors qu'un seul OTP est consigné ou deux utilisateurs connectés localement alors qu'un seul badge accès physique a été activé).

• L'exigence #8.7 précise que seuls les DBA sont autorisés à accéder directement aux bases de données. Si vous avez des collaborateurs exclusivement DBA, n'oubliez pas de vérifier que vos Sysops/Webops ne disposent de privilèges similaires ou modifiez leur fiche de fonction/poste pour préciser qu'ils peuvent également assurer ce rôle.

• L'exigence #9.6.2b précise que votre QSA sélectionnera un échantillon de pistes d'audit pour les medias conservés hors site et qu'il vérifiera, via l'exigence #9.7.1, que vous avez tenu à jour, à minima annuellement, un inventaire exhaustif de tous les médias utilisés au sein du périmètre PCIDSS.

Regularly Monitor and Test Networks

Le cinquième ensemble d'exigences ("10. Track and monitor all access to network resources and cardholder data" et "11. Regularly test security systems and processes") nécessite des collaborateurs de votre Direction Informatique qu'ils disposent d'un bagage sécurité fonctionnel et technique (ou qu'ils soient accompagnés/conseillés). Dans ce cas, cet ensemble d'exigences est pour nous l'un des plus simples à respecter (soit vous appliquez l'exigence soit vous êtes non conforme - nulle possibilité pour se faufiler). Quelques exemples de non conformité qui vous paraitront triviaux mais qui peuvent être néanmoins faciles à oublier.

• L'exigence #10.3 relative à la traçabilité requiert qu'un certain nombre de critère soit consignés dans les pistes d'audits et détaille une liste précise d'éléments à enregistrer tout en précisant qu'il s'agit du minimum imposé. La guidance de cette exigence précise néanmoins que les pistes d'audits doivent faire l'objet d'enregistrements permettant d'identifier rapidement toute compromission potentielle et avec suffisamment de détails pour savoir qui, quoi, ou, quand et comment. Si les éléments imposés ne sont pas suffisants dans votre contexte, vous devrez donc en paramétrer de nouveaux afin d'être conformes.

• L'exigence #10.4 relative à la synchronisation temporaire des composants est imposée pour tous les systèmes considérés comme critiques. Bien entendu, les éléments critiques ne sont pas tous composants du CDE ou en frontière de celui-ci. Les composants permettant de répondre à certains exigences précises ou desquels dépendent des fonctions de sécurité annexe sont également concernés (exemple type : serveurs de messagerie électronique ou serveurs DNS).

• L'exigence #10.5.4 relative à la sécurisation des pistes d'audit précise une modalité spécifique pour la conservation des journaux relatifs aux composants systèmes avec une surface d'exposition externe/publique/internet et indique en guidance que les évènements propres aux technologies sans-fil (Wireless), aux pare-feu, aux DNS et aux serveurs de messagerie sont concernés. Si vous appliquez déjà les préceptes Business As Usual et respectez l'esprit de la norme, vous n'aurez pour nous pas de problème à ce niveau là car vous aurez déjà géré ce cas. Dans le cas contraire, relisez attentivement chaque item.

• L'exigence #10.6.2 relative à la revue périodique et régulière des évènements de sécurité survenant sur le Système d'Information précise deux cadres de revue : l'un est imposé pour un certain nombre précis d'évènements (eg: sécurité) ou de composants (eg: CDE, critiques, sécurité) alors que l'autre concerne tous les autres systèmes en imposant un sous-jacent respectant l'analyse de risques correspondantes (indice : pensez matriochki). La même exigence impose du processus de revue qu'il intègre la revue des évènements permettant d'obtenir un accès aux systèmes sensibles à partir de systèmes non sensibles (eg: tentatives à destination du scope PCIDSS en provenance de ce qui est non scope PCIDSS).

• L'exigence #10.8 relatives à la documentation des processus de surveillance impose la formalisation de procédures opérationnelles qu'il serait bon de documenter au plus tôt afin qu'elles soient comprises et connues par les collaborateurs (eg: ne pensez pas que les règles de votre IDS ou la configuration de votre SIEM font office de procédures opérationnelles).

• L'exigence #11.1 relative à la détection préventives de technologies sans-fil impose qu'une surveillance/revue préventive soit documentée et appliquée et ce même si vos politiques interdisent l'usage de telles technologies (n'oubliez pas de lire attentivement les guidances). De même l'exigence #11.1.2 précise bien que dans le cas où les politiques de sécurité interdisent l'usage de technologies sans-fil, le plan de réponse sur incident doit néanmoins inclure une procédure relative à la détection de points d'accès non autorisés.

• L'exigence #11.2 est pleine de petits pièges techniques : n'oubliez pas que les scans internes/externes doivent être fait de manière trimestriel mais également après chaque changement significatif (la définition de ce significatif, up to the QSA dirons nous, sera évidement plus simple à formaliser si votre responsable de conformité PCIDSS dispose d'une expérience en tant qu'auditeur). N'oubliez pas non plus que vous avez à répéter les scans une fois que les vulnérabilités sont corrigées (eg : dans un mode de scan trimestriel exclusivement car peu de changements significatifs, n'oubliez pas de tourner les scans de contrôle avant l'échéance trimestrielle).

• L'exigence #11.2.1 est l'une des exigences que nous affectionnons dans ce standard et qui impose que les audits de vulnérabilité internes soient réalisés par des équipes/collaborateurs qualifiés et raisonnablement indépendants. Pour nous, un collaborateur qualifié n'est pas un simple utilisateur qui clique pour lancer un scan, télécharge un PDF et le dépose sur un partage : il doit comprendre comment fonctionnent les outils qu'il utilise, il doit être capable de les configurer et d'expliquer techniquement pourquoi les vulnérabilités sont identifiées, comment elles le sont et comment y remédier de manière conforme au standard et aux politiques de sécurité en vigueur. Similairement, pour nous un collaborateur raisonnablement indépendant doit être autorisé à escalader la résolution des vulnérabilités entrainant une non conformité hors de l'environnement propre à la Direction Informatique (nous apprécions particulièrement cette exigence car, sous un aspect purement organisationnel lié à un impératif technique, son application peut entrainer positivement de profondes modification de la chaine décisionnelle sécurité au sein d'une organisation).

• L'exigence #11.2.3 est intéressante dans le sens où la corrélation de la documentation propre aux changements du Système d'Information (besoins métier ou adaptation au schéma directeur informatique) avec les conclusions d'audits de vulnérabilités peut être réalisée par les responsables du changements ou par les responsables des audits. Cette formalisation sera donc toujours fonction des profils des intervenants et particulièrement riche d'enseignements en fonction des organisations.

• L'exigence #11.3 relative aux tests d'intrusion présente une difficulté majeure au niveau du 7eme item imposé ("Includes review and consideration of threats and vulnerabilities experienced in the last 12 months") : Veillez à bien informer vos prestataires de cette obligation (qui doivent, à notre avis, travailler avec vous et non pour vous) ou à vous assurer que vos personnels internes qualifiés savent comment formaliser cette nouvelle obligation. Notez que cette exigence est considérée comme best practice jusqu'en juin 2015 mais nous vous conseillons de vous appliquer à la respecter dès que possible. La même exigence dans sa guidance suggère que vous ne pourrez totalement interdire l'exploitation des vulnérabilités identifiées en test d'intrusion ce qui peut poser problème pour certaines organisations habituées à s'arrêter à l'identification des vulnérabilités (crainte d'atteinte à la production ou volonté de réduction des coûts).

• Les exigences #11.3.1 et #11.3.2 (11.3 en version 2) relatives à la réalisation de tests d'intrusion internes et externes est l'une des exigences souvent sous-estimée pour les environnements qui sont sujets à des évolutions fréquentes (exemple type pour les cyber marchands mettant en œuvre des développements en mode agile avec des sprints courts pour répondre aux attentes du marché) : il est ainsi imposé de réaliser ces tests d'intrusion une fois par an mais également après chaque changement significatif ce qui peut entrainer une augmentation des coûts significatives si cet aspect est compris tardivement. Pensez également que l'application des correctifs de sécurité publiés par les éditeurs (exemple type: patch tuesday de Microsoft) peut fréquemment être considéré comme un changement significatif.

• L'exigence #11.5.1 relative à l'implémentation de mécanismes de détection de changement est pour nous fréquemment l'objet de "vous êtes certaines? Relisons la norme ensemble". Les mécanismes de détection des changements que vous avez déployés et qui tournent 24/7/265 en remontant des alertes à vos administrateurs - alertes qui sont correctement gérées par ces administrateurs. N'oubliez pas que vous devez disposer d'un processus formalisé et d'un modèle de document pour la gestion de ces alertes.

Pour conclure ce chapitre et si vous disposez d'une expérience en terme d'auditeur vous avez déjà compris où nous souhaitons en venir. Il n'est pas possible de feinter l'une des exigences précédentes car toutes s'emboitent telles des poupées russes et sont autant de questions pièges à la disposition du QSA pour savoir où il met les pieds.

Maintain an Information Security Policy

Le sixième et dernier ensemble d'exigences ("12. Maintain a policy that addresses information security for all personnel") est selon nous le chapitre le plus compliqué à mettre en œuvre quand la responsabilité de conformité au standard PCIDSS est confiée à un intervenant avec un profil technique qui ne dispose pas (ou peu) d'expérience en matière de sécurité organisationnelle et fonctionnelle. Nous recommandons souvent aux organisations concernées d'être assistée ou conseillée dans la formalisation ou la maitrise d'ouvrage afférente au respect de ces exigences.

• L'exigence #12.10.4 impose un entrainement régulier des équipes/collaborateurs en charge de la réponse aux incidents de sécurité. Il ne s'agit pas ici d'être capable techniquement d'identifier un incident ou d'y répondre par des mesures techniques mais de s'assurer que le processus global de gestion des incidents de sécurité respecte les obligations imposées par le standard et que l'ensemble des intervenants est au fait de ses devoirs et obligations.

• L'exigence #12.2 impose que le processus afférent à la gestion des risques soit mis en oeuvre après chaque changement significatif. Il est donc recommandé d'intégrer la mise à jour périodique des analyses de risques en mode Business as Usual et de ne pas attendre l'échéance des audits de conformité PCIDSS pour ce faire.

• L'exigence #12.3 relative à la formalisation de politiques d'usage des technologies sensibles impose avec l'exigence #12.3.7 de maintenir une liste de produits approuvés par l'entreprise. N'oubliez pas que ces produits doivent ensuite respecter l'ensemble des autres exigences du standard (exemple non exhaustif : exigences #6.1/#6.2, #10, #11.1 etc.).

• L'exigence #12.3.9 impose que les accès à distance pour les vendeurs ou partenaires ne soient activés que s'ils sont strictement nécessaires et qu'ils soient immédiatement désactivés après usage. N'oubliez pas que ces accès doivent être tracés et faire l'objet de pistes d'audits présentables au QSA lors de son audit.

• L'exigence #12.5 est l'une de nos exigence préférées car elle témoigne bien du bon sens des rédacteurs du standard PCIDSS en ce qu'elle impose que les prérogatives afférentes à la Sécurité de l'Information soit formellement attribuées à un CSO ou à un "other security-knowledgeable member of management". Il est donc tout à fait possible pour une organisation d'attribuer la responsabilité SSI à un membre de la Direction pour autant que celui-ci soit assisté/conseillé par des tiers (internes ou externes) qualifiés dans ce domaine. Notez que nous déconseillons l'attribution de ces responsabilités aux collaborateurs dirigeants de la Direction Informatique ou aux opérationnels en charge du périmètre PCIDSS pour que l'indépendance des contrôles et recommandations soit préservée et conforme à l'esprit du standard et des bonnes pratiques.

• L'exigence #12.6 pour l'implémentation d'un programme de sensibilisation des collaborateurs nécessite que ceux-ci soient formés à l'importance de la sécurité propre à la protection des données cartes. N'oubliez pas que le QSA peut demander copie des supports de cette sensibilisation : si vous avez parlé de tout mais pas des données cartes, alors Houston, vous avez un problème. L'exigence #12.6.2 impose par ailleurs de son côté que l'ensemble des collaborateurs reconnaisse (au moins annuellement) qu'ils ont lu et compris les politiques de sécurité (la dimension manuscrite ou électronique de cette exigence permettant aux programmes d'elearning d'apporter les pistes d'audits nécessaires et suffisantes).