dimanche 18 août 2013

Le PCI Council publie un aperçu des changements de la version 3.0 de PCI DSS



Le PCI Security Standards Council a mis en ligne un aperçu de la version 3.0 de PCI DSS et de PA-DSS qui sera publiée officiellement le 7 novembre 2013. 

Pour rappel ces changements prennent en comptes les recommandations de la communauté PCI en réponse aux besoins du secteur, l’Europe a pour sa part contribué à hauteur de 27% derrière l’Amérique du Nord avec 49%.

Pas de modification de la structure des 12 exigences PCI DSS, en revanche plusieurs nouvelles sous-exigences sont à prévoir, l’objectif de la version 3.0 reste la flexibilité de mise en œuvre des exigences selon le PCI SSC.

Au total une douzaine de changements notables sont proposées dans la version 3.0, avec un accent sur la documentation du périmètre et du flux de données cartes que nous avions déjà évoqué dans un précédent billet, la gestion des vulnérabilités et la détection des logiciels malveillants, les test d’intrusions par les commerçants, plus de flexibilité concernant les exigences de mots de passe et l’exigence 12 repensée et très orientée gestion de la conformité PCI des fournisseurs de services.

Bob Russo (General Manager du PCI SSC)  a également rappelé lors d’une récente interview pour SearchSecurity que la version 3.0 de PCI DSS est de complétement intégrer la conformité PCI aux activités du commerçant et son métier au jour le jour « business as usual ». Et que la mission du PCI SSC est d’aider les commerçants à protéger les données cartes où qu’elles soient conservées, traitées et transmises.

A ce stade ce ne sont que des propositions qui démontrent néanmoins de fortes tendances :

Maintien d’un inventaire des composants dans le périmètre PCI

Afin de faciliter la gestion du périmètre PCI, le maintien d’un inventaire de l’ensemble de ses composants dans ce périmètre devra être assuré. Au passage pour ceux qui sont déjà certifiés PCI DSS cet inventaire est une exigence du ROC (Report On Compliance) qui fait partie intégrante de la l’« Executive Summary » de ce dernier. Ne pas hésiter donc à réutiliser ce qui a déjà été fait et le maintenir !

Le changement de mots de passe par défaut va devenir une exigence pour les applications et les comptes de services, ainsi que les comptes d'utilisateurs dans la version 3.0.

Documentation d’un diagramme des flux de données carte

A la différence de la version 2.0 de PCI DSS qui exige un diagramme réseau qui doit documenter toutes les connexions aux données cartes, la version 3.0 devrait exiger un diagramme qui documente les flux de données cartes afin de voir comment ces données circulent à travers les composants documentés dans le diagramme réseau.

Evolution des menaces liées aux logiciels malveillants

Dans la version 2.0 de PCI DSS il suffisait de dire que mon système d’exploitation n’est pas affecté par des logiciels malveillants pour rendre inapplicable l’exigence 5.1 (Déployer des logiciels antivirus sur tous les systèmes régulièrement affectés par des logiciels malveillants). PCI DSS version 3.0 propose à présent d’évaluer la menace des logiciels malveillants des composants non affectés par ces derniers. Ce qui constitue une évolution majeure en contradiction avec l’ensemble des pratiques jusqu’à maintenant retenues par certains, elle risque de surcroît d’être très interprétable mais reste louable quand on voit l’évolution des logiciels malveillants au niveau du point de vente par exemple.

Alignement des pratiques de développements en réponse aux menaces émergeantes

PCI DSS version 3.0 rappel l’importance de répondre aux menaces émergeantes des applications qui traitent, conservent et transmettent des données cartes. Cette proposition devra être portée par les pratiques de développement sécurisé existantes afin d’y inclure les bonnes pratiques d’organismes reconnus comme l’OWASP, le NIST, le SANS, l'ANSSI ... dans la gestion des vulnérabilités courantes.

Ouverture aux autres méthodes d’authentifications et plus de flexibilité dans le choix de la politique de mot de passe 

Pour répondre aux retours de la communauté PCI concernant les méthodes d’authentifications autres que les mots de passe, la version 3.0 de PCI DSS devraient prendre en considération des mécanismes d'authentification reposant sur des jetons physiques, des cartes à puce ou des certificats.

Plusieurs changements sont également proposés pour l’exigence 8 de PCI DSS (Affecter un ID unique à chaque utilisateur d’ordinateur), notamment des propositions pour une plus grande flexibilité dans la force et la complexité du mot de passe avec des combinaisons équivalentes, ainsi que des recommandations afin de laisser le choix aux utilisateurs de choisir des mots de passe robustes, protéger leurs informations d'identification et de changer les mots de passe en cas de soupçon de compromission. 

Protection des terminaux de paiement contre les attaques physiques 

Pour répondre à l’explosion des attaques sur les terminaux de paiements, l’exigence 9 (Restreindre l’accès physique aux données des titulaires de cartes) devrait intégrer de nouvelles exigences de protections des terminaux et autres dispositifs de paiement contre l’altération, la substitution ou autre attaque physique. Cela devrait se traduire par des vérifications de base comme les inventaires, les numéros de séries, état physique du terminal ... 

Mise en œuvre d’une méthodologie de tests d’intrusion 

Les changements apportés à l’exigence 11 (Tester régulièrement les processus et les systèmes de sécurité) risquent de créer la controverse avec la mise en œuvre d'une méthodologie de tests d’intrusions, et la validation par ces tests de l’étanchéité du périmètre qui doit être opérationnelle et effective. 

Clarification des responsabilités pour les commerçants qui s’appuient sur des fournisseurs de services 

Pour les commerçants les nouvelles exigences devraient insister sur le maintien des informations concernant les exigences PCI DSS gérées par le fournisseur de services et celles gérées par les commerçants eux-mêmes, ce qui obligerait les fournisseurs de services à reconnaître leur responsabilité de maintenir les exigences PCI DSS applicables. Une grande partie de ce qui était couvert dans l’exigence 12 (Gérer une politique de sécurité des informations pour l'ensemble du personnel) concernant la politique de sécurité devrait être également intégrée dans les autres exigences.

Les modifications de l'exigence 12 sont en autre une réponse pour les commerçants qui utilisent le Cloud comme un élément de leur infrastructure de traitement des paiements. À ce jour, la conformité PCI DSS du Cloud reste complexe en terme de responsabilités et de périmètre également pour les QSAs (Qualified Security Assessors) sans parler des investigations à l’issue d’une compromission.

La nouvelle exigence respose également sur une approche par les risques promue par le PCI SSC compte tenu des nouveaux canaux d’acceptations mobiles, enfin qui parle de responsabilités parle de partage des risques et des pénalités en cas de compromission. Ce qui permettra de dissuader les commerçants de s’assurer de la conformité de leurs fournisseurs de services et permettra à ces derniers de répondre à leurs engagements.

lundi 31 décembre 2012

PCI DSS version 3, les nouveautés attendues en 2013

Comme chaque année le PCI SSC a rassemblé « sa communauté » autour de son Community Meetings, événement majeur pour échanger avec les QSAs, les réseaux cartes, les clients, fournisseurs et tout autre acteur concerné par PCI. La cinquième édition de cet événement s’est clôturée en octobre 2012 à Dublin avec son lot de nouveautés pour 2013.

La publication officielle de la version 3 de PCI DSS est attendue pour octobre 2013 (la version intermédiaire devrait être disponible en avril 2013).  Cette version devrait clarifier (un peu plus) le périmètre PCI DSS alors que la communauté non PCI a déjà pris les devants avec l’initiative de l'Open PCI DSS Scoping toolkit.

La version 3 de PCI DSS fournira des orientations précises sur la définition du périmètre et la segmentation réseau requise. Notamment les règles suivantes issues principalement de retour d’expérience QSAs :
  • Tout système impactant la sécurité de l’environnement de données porteurs est considéré dans le périmètre PCI,
  • Pour être complètement hors périmètre PCI, un réseau ou un système doit être isolé de l’environnement de données porteurs sans aucune connectivité à ce dernier,
  • La mise en œuvre de liste de contrôle d’accès (au niveau IP ou port) peut  limiter l’exposition de l’environnement de données porteurs mais ne supprime pas automatiquement les systèmes et les réseaux du périmètre si une connectivité existe,
  • Dans le cas ou des connections à l’environnement de données porteurs sont limitées à des ports ou des services spécifiques, les systèmes concernés sont à prendre en compte dans le périmètre afin de vérifier que les exigences PCI DSS sont en place,
  • Le QSA ou l’ISA doit également déterminer si les systèmes connectés ouvrent la porte ou fournissent un chemin vers d’autres systèmes dans l’environnement de données porteurs,
  • Les exigences PCI DSS applicables peuvent varier et dépendre de la fonction du système et de la présence d’autres mesures en place,
  • Les systèmes qui assurent des fonctions de troncage, masquage, tokénisation ou « hachage » des numéros de cartes sont dans le périmètre PCI et doivent être isolés de ceux qui les conservent,
  • Les QSAs devront confirmer qu’un système ne peut pas impacter la sécurité de l’environnement de données porteurs afin de déterminer qu’il est hors périmètre.
Le PCI SSC devait en effet apporter plus de clarification sur le sujet du périmètre PCI car c’est un indispensable et surtout un axe stratégique à tout projet PCI DSS. Il est pour ma part un peu dommage de ne pas avoir clarifié le périmètre PCI dans les premières itérations de PCI DSS. L’inconvénient majeur qu’on peut attendre et clairement de ne pas avoir pris en compte ces mesures et d’avoir à inclure dans le périmètre des composants auxquels ont auraient jamais pensé à prendre en compte, l’Active Directory par exemple accompagné de la solution de sauvegarde entreprise !

Plus de clarifications des exigences PCI concernant le chiffrement des données porteurs :
  • Les données porteurs chiffrées restent dans le périmètre PCI dans la mesure où ces données peuvent être déchiffrées avec une clé disponible au sein de l’entité,
  • D’une manière générale les données chiffrées sont de la responsabilité de l’entité qui contrôles et ou dispose d’un accès aux données chiffrées et aux clés,
  • Les données porteurs chiffrées peuvent être considérées hors périmètre PCI dans le cas uniquement où l’entité ne dispose pas des clés pour les déchiffrer (Il est donc possible de mettre hors périmètre des données chiffrées, c’est généralement déjà le cas lors de l’archivage de données ou de sauvegarde de données en reste au niveau d’une base de données par exemple),
  • Les systèmes assurant les fonctions de chiffrement et déchiffrement de données porteurs, ainsi que tout système assurant des fonctions de gestion de clés sont toujours considéré dans le périmètre PCI.
Autres tendances discutés lors du PCI SSC Community Meetings :
  • Exigence d’utiliser des fournisseurs de scans ASVs pour la réalisation des scans internes (pré-requis 11.2),
  • Clarification des termes « si les données de titulaires de cartes sont partagés avec des prestataires de services » et fournir davantage de prescriptions standardisés d’accords écrits qui s'appliquent aux fournisseurs de services (pré-requis 12.8),
  • Mise à jour des questionnaires d’auto-évaluation (SAQs) trop complexes,  difficile à comprendre ou pas assez détaillé,
  • Mise à jour des exigences de mot de passe (et l’étendre au-delà des mots de passe). Les exigences de mot de passe actuelles sont soit trop stricte ou pas assez strict selon le PCI SSC (pré-requis 8.5),
  • Etendre le périmètre d’éligibilité des exigences PA-DSS aux applications qui n’assurent pas de fonction de paiement, applications sur mesures ou embarquées dans les terminaux, 
  • Développement d’exigences PA-DSS en réponse aux différentes technologies tel que tel le terminal mobile, EMV … 
  • Tokenization : un nouveau standard (et sans doute une nouvelle certification de solutions à l’image de P2PE) devrait voir le jour en 2013.
    Sécurité physique PCI
    • Il n’est pas exclut de voir apparaitre de nouvelles exigences de sécurité physique dans la version 3 de PCI DSS (sans doute en réponse à la vague "skimming" qui ne cesse d'augmenter depuis plusieurs mois).

    vendredi 16 novembre 2012

    Recommandations pour l'analyse de risque PCI

    Le PCI Security Standards Council a mis en ligne aujourd'hui une nouvelle série de recommandations pour l'évaluation des risques dans un contexte PCI. C’est un document assez complet en termes d’approche et de méthodologie, des exemples et une démarche sont également proposés afin de préciser les attentes de l’exigence PCI DSS 12.1.2. Le document a été rédigé par plus de 60 sociétés représentant banques, commerçants, QSAs et consultants sécurité, fournisseurs de service et de technologie.

    Les premières itérations de l’exigence 12.1.2 a provoqué quelques mécontentements des entreprises concernées par PCI il y a quelques années. En effet certaines ne comprenaient pas l’intérêt de faire une analyse de risque alors que d’autres ne disposaient pas des compétences requises où la réalisée  partiellement avec les métiers sans formalisation quelconque ni méthodologie, et la sécurité des données porteurs n’étaient que rarement couverte par l’analyse de risque.


    Je vous propose à présent de partager avec vous mes commentaires sur ce nouveau document : 
    • Le document invite à intégrer la démarche d’analyse de risque PCI au programme de gestion des risques de l’entreprise. Je partage totalement cette recommandation car PCI ne doit pas être une démarche isolée au sein de l’entreprise mais au contraire complètement intégrée, et cela s’applique également à l’analyse de risque qui doit au minimum impliquer les métiers et l’IT et non se limiter qu’à une seule population. A noter que la sécurité des données porteurs à un impact sur l’entreprise et son image de marque,
    • L’analyse de risque PCI est un axe de réduction du périmètre. L’issue d’une analyse de risque PCI permettrait d’identifier la présence de données porteurs non requises par les métiers et donc à supprimer. Les conséquences sont un impact direct sur le périmètre PCI et sa réduction,
    • Le document ne recommande l’utilisation d’une méthodologie type pour l'analyse de risque mais rappel simplement les principales existantes sur lesquelles on peut à s’appuyer à savoir ISO 27005, NIST SP 800-30 et Octave. Au passage Ebios et Mehari conviennent également très bien. En revanche le PCI SSC recommande de créer sa propre méthodologie d’analyse de risque afin de l’adapter à ses spécificités métiers. Cette méthodologie devra néanmoins s’appuyer sur les grands principes de l’analyse de risque et l’état de l’art en vigueur,
    • Lors de l’étape d’identification des « biens » de l’entreprise, le PCI SSC recommande une catégorisation par canaux d’acceptations (MOTO, face-to-face, e-commerce …) avec en amont l’identification du propriétaire de la donnée et de sa protection.  L’approche par canaux est intéressante mais l’identification du propriétaire et de sa protection peut présenter une certaine complexité au sein d’un grand accepteur ou une banque, en effet le propriétaire de la donnée n’est pas forcément celui qui assure la responsabilité de sa protection,
     
    • La section traitement des risques est très standard sans réel apport ou même retour d’expérience, la note suivante présente dans le document justifie ce constat : « Une analyse des risques ne peut aboutir à l’acceptation, le transfert ou le partage de risques qui aura pour conséquence une non-conformité PCI DSS »,
    • Le document rappel les risques induits par les tiers, c’est un point important avec un rappel des catégories de risques auxquelles on doit s’attendre lorsqu’on on fait appel à des tiers. Les tiers peuvent « introduire, gérer et partager des risques »,
     
    •  Enfin le document fait des recommandations d’un rapport type qui devrait inclure : le périmètre de l’analyse de risque, l’inventaire des biens, les menaces, les vulnérabilités, l’évaluation des risques et son traitement, la version du rapport et un sommaire exécutif. Ce ne sont que des recommandations et non des exigences, n’hésitez pas à le rappeler à vos QSAs !
    En conclusion le document est une bonne source d’information pour ceux qui n’ont pas encore démarré la démarche d’analyse de risque PCI. De mon coté je vous recommande  en complément de prendre connaissance des guides de la CNIL qui ont une approche autour de la donnée et non exclusivement PCI. L’intérêt est de pouvoir capitaliser sur le travail déjà réalisé dans le cadre de PCI (ou tout simplement d'avoir une approche plus large au sein de l'entreprise avec une approche autour de la donnée) pour l’étendre au reste compte tenu des exigences de la CNIL.

    jeudi 30 août 2012

    Comprendre le chiffrement bout en bout P2PE (Point-to-Point Encryption)



    Le PCI Council a récemment publié une FAQ pour répondre aux questions les plus fréquentes autour du chiffrement bout en bout P2PE. En effet après la publication des exigences PCI P2PE en début d’année le PCI SSC se devait de clarifier et d’expliquer ce sujet qui n’est pas sans impact pour un commerçant. 

    En synthèse voici quelques une des questions que j’ai pris le soin de commenter :

    Qu’est ce qu’une solution de chiffrement bout en bout P2PE (Point-to-Point Encryption) ?

    Une solution de chiffrement bout en bout P2PE est une combinaison de dispositifs de sécurité, d’applications et de processus permettant de chiffrer les données du point d’interaction (ou d’acceptation de la transaction) jusqu'au tiers fournissant le service et l’environnement de déchiffrement.

    Une solution de chiffrement bout en bout P2PE doit nécessairement inclure les éléments suivants :
    • Un chiffrement robuste et sécurisé des données de paiement par carte au point d’interaction,
    • Une application P2PE validée par le PCI SSC installée sur le point d’interaction (il s’agit généralement des applications embarquées dans les terminaux),
    • Une gestion sécurisée des dispositifs de chiffrement et de déchiffrement,
    • Une gestion de l'environnement de déchiffrement et de l’ensemble des données de paiements déchiffrées,
    • L’utilisation de méthodes de chiffrement et de gestion opérationnelle des clés robustes, notamment dans le cadre de la génération, la distribution, le chargement ou l’injection, l’administration et l’utilisation des clés (DUKPT semble faire l’unanimité en terme de gestion des clés pour du P2PE, en revanche la mise en œuvre reste complexe pour les non initiés). 
    Qu’est ce qu’un fournisseur de solution de chiffrement bout en bout P2PE ?

    Un fournisseur de solution P2PE est une entité tierce (par exemple un processeur, acquéreur, ou même encore une passerelle de paiement) qui la responsabilité globale de la conception et de la mise en œuvre de la solution, et gère des solutions P2PE pour ses commerçants. Le fournisseur de la solution doit également veiller à ce que toutes les exigences P2PE sont remplies, y compris les exigences P2PE effectuées par des organismes tiers pour le compte du fournisseur (par exemple les autorités de certification ou les injections de clés dans les dispositifs de sécurité lorsque cela est applicable).

    Qu’est ce que le standard Point-to-Point Encryption (P2PE) ?

    Le standard PCI P2PE est une liste d'exigences de sécurité associée à des procédures de tests des applications et des solutions P2PE. L'objectif est de s'assurer que les applications et les solutions P2PE peuvent répondre aux exigences nécessaires à la protection des données de cartes de paiement.

    Est-ce que les commerçants qui utilisent des solutions P2PE sont considérés hors périmètre PCI ?


    Les commerçants qui utilisent des solutions P2PE ne sont pas considérés comme hors périmètre PCI. Cependant l’utilisation de solutions P2PE peut réduire considérablement leur périmètre, plusieurs éléments sont à prendre en compte notamment la solution P2PE mise en œuvre et le travail de préparation réalisé en amont.

    L'environnement du commerçant reste donc dans le périmètre PCI dans la mesure où les données porteurs y sont toujours présentes. Dans un environnement carte présente les commerçants ont un généralement toujours accès physique aux cartes de paiement afin de compléter une transaction par exemple, ainsi qu'aux tickets commerçants avec le numéro de carte en clair.

    Est-ce la version des exigences P2PE est applicable aux commerçants qui ont développé leur propre solution P2PE ?

    La version 1.1 du standard P2PE s'applique uniquement aux fournisseurs de solutions P2PE et non aux commerçants qui ont développé leur propre solution P2PE. Dans ce cadre toutes les opérations de chiffrement et de déchiffrement, ainsi que toutes les clés sont gérées par un fournisseur de solution tierce.

    Cependant le PCI SSC précise que les prochaines phases du standard P2PE traiteront les scénarios où les commerçants géreront leurs propres clés de chiffrement ainsi que leurs données.

    mercredi 8 août 2012

    Une boite à outils pour définir son périmètre PCI


    Une initiative intéressante de « l’Open Scoping Framework Group » qui à travers une démarche structurée et sa boite à outils vous accompagne dans la définition de votre périmètre PCI.

    Les auteurs rappellent néanmoins que la démarche n’est à utiliser qu’à l’issue d’une première identification des données porteurs au sein de l’entreprise, rappelant que cette dernière doit être documentée et permettre d’identifier où les données porteurs sont conservées, transmises et traitées. Cette boite à outils peut être utilisé par les grandes et les petites avec comme différence évidente le nombre de systèmes retenus dans le périmètre PCI.
     
    L’on retrouve dans la démarche proposée les grands principes d’une définition de périmètre très orientée QSAs à mon sens avec notamment une catégorisation des systèmes du périmètre PCI en fonction :
    • Du type de traitement des systèmes dans le périmètre PCI, à savoir si les systèmes traitent, stockent ou transmettent des données porteurs,
    • La fonction et le rôle des systèmes dans le périmètre PCI (exemple : système d’autorisation, d’authentification, de surveillance …),
    • La connectivité entre les systèmes et l’environnement de données porteurs.
    Outre le fait que cela permettra de faciliter le travail fastidieux de la définition du périmètre, cette boite à outils ne couvre que partiellement le périmètre PCI qui doit également inclure les processus, le personnel … en charge de l’environnement de données porteurs conformément aux conditions PCI DSS.

    Pour ma part c’est une initiative intéressante, également pour les QSAs car une finalité même si elle n’est pas clairement exprimée est de faciliter la rédaction du ROC (Report On Compliance) requis pour valider la conformité PCI DSS. Il est dommage cependant que le PCI SSC ne soit pas plus impliqué dans cette initiative.

    La démarche va plus loin que le standard PCI DSS qui catégorisent les composants soit dans le périmètre ou soit à l’extérieur avec une notion de système connecté qui reste à l’appréciation et la compréhension du QSA de votre environnement de données porteurs. 

    Afin de faciliter la définition du périmètre PCI « l’Open Scoping Framework Group » a définit trois catégories de composants, et met en évidence les différents types de risques associés à chaque catégorie. Cela permet de mettre en avant les systèmes les plus importants à protéger à travers une approche par les types de risques qu'elles posent aux données porteurs

    Chaque système au sein de l'environnement informatique d'une entreprise peut être classé en une seule opération :
    • Catégorie 1 : les systèmes qui traitent, stockent et transmettent les données porteurs  ou non isolés ou limités par un accès contrôlé à partir d'autres systèmes de cette même catégorie,
    • Catégorie 2 : les systèmes qui ont un accès contrôlé aux systèmes de la catégorie 1,
    • Catégorie 3 : les systèmes isolés de tout système de la catégorie 1.

    vendredi 27 juillet 2012

    Baisse de la fraude à la carte bancaire en Europe

    La BCE (Banque Centrale Européenne) publie pour la première fois une étude sur les fraudes à la carte bancaire. L’étude a portée sur les pays de la zone SEPA soit les 27 pays de l'Union européenne, plus l'Islande, le Liechtenstein, Monaco, la Norvège et la Suisse comptant au total 458 millions de citoyens européens. Selon la BCE la raison principale de la baisse de la fraude aux distributeurs de billets et aux terminaux de point de vente entre 2007 et 2010 est due entre autre à l’amélioration de la sécurité des cartes et de l'infrastructure de paiement avec notamment l'adoption élargie de la carte à puce.

    L'étude de la BCE relève : 
    • Le montant total de la fraude est en recul de 12,1% par rapport à 2009, il a été évalué à 1,26 milliard d'euros en 2012,
    • Au total 1,2% des cartes bancaires de la zone SEPA ont été utilisées frauduleusement,
    • Les fraudes provenant des paiements à distances (Carte Non Présente) sont en tête des fraudes avec Internet aux premières places pour 74 des cas. En 2010, elles représentaient 50 % de l’ensemble des infractions soit 648 millions d’euros, contre 47% en 2007,
    • La BCE recommande davantage de prévention avec l’adoption de normes internationales (PCI DSS ?) notamment sur Internet.
    • Les fraudeurs de la zone SEPA ont beaucoup plus comptés sur les fraudes ciblant les ATM (Automatic Teller Machine) et les POS (Point of Sale) que les fraudes provenant des paiements à distances (CNP),
    • La contrefaçon reste la première source de fraudes sur les ATM et les POS avec 344 millions d’euros en 2010, avec la contrefaçon comme première source de fraude, les cartes volées ou perdues ont représentées pour leur part 215 millions d’euros,
    • 25% de fraude pour les 2% de paiements transfrontaliers acquis hors zone SEPA.