[00:00:05] Aujourd'hui, seconde partie est très en retard. Là je pense que j'ai battu les records, désolé. Désolé, seconde partie du sujet PCI DSS que j'avais lancé initialement au mois de novembre. Dans cette partie ici avec mon invité, on a parlé plus tôt des mythes et du parcours d'obtention de la PCI DSS. Mon invité c'est de nouveau Kevin Dejour, ancien RSSI et maintenant auditeur PCI DSS qualifié ou dit QSA.

[00:00:32] Je suis Michael VIRGONE, passionné par la cybersécurité. Bienvenue sur mon podcast Cybersécurité All Day. Et avant de commencer déjà, je tiens à vous souhaiter une très belle année 2025, la santé car c'est à mon sens le plus important, le bonheur et la réussite. Et voici la seconde partie de mon échange avec Kevin. Écoute on va passer sur la seconde partie, on va parler des mythes et des pratiques. Et ça du coup je le rappelle parce qu'on en avait parlé dans la première partie, c'est que toi à l'époque tu avais été audité en tant que RSSI

[00:01:00] et maintenant c'est toi qui fais les audits. Donc on va dire que tu es passé entre guillemets du côté obscur de la force. Forcément tu as vu donc les deux aspects. Et l'un des mythes dont tu m'évoquais, c'était que par exemple j'utilise des prestataires certifiés, donc je suis certifié. Et ça apparemment c'est un mythe justement qui est incorrect. Il y a la vie dure en tout cas. Effectivement, il y a un certain nombre de choses qui peuvent être externalisées,

[00:01:28] mais toutes les exigences ne peuvent pas être externalisées. Par exemple, on l'a vu tout à l'heure, il y a des exigences qui sont relatives à la sécurité du réseau, qui sont relatives à la sécurité des systèmes. Ça, ça peut être un faut gérer auprès d'un prestataire, il n'y a pas de souci. Donc ça va être le prestataire, s'il est certifié PCDSS, l'entreprise en question va devoir s'assurer que le prestataire en question est bien certifié PCDSS. On peut également externaliser, en tout cas on peut l'imaginer, la partie sécurité physique.

[00:01:58] On a un data center, ça va être le data center qui va s'engager sur la certification PCDSS pour s'assurer qu'effectivement ils sont conformes sur le chapitre 9, donc sur la partie sécurité physique. Il y a bien les caméras qui sont bien mis au bon endroit, il y a bien du contrôle d'accès sur les portes pour accéder à la salle serveur, etc. Mais il y a une exigence qu'on va avoir du mal à externaliser, ça va être par exemple la gestion des prestataires. Il est au moins demandé que l'entreprise en question qui est responsable des prestataires qu'elle engage

[00:02:27] a un programme pour s'assurer annuellement que les entreprises en question, que les prestataires en question sont toujours certifiés PCDSS. Il faut également qu'il y ait un accord, un contrat par exemple, comme quoi les prestataires reconnaissent qu'ils vont récupérer des numéros de cartes bancaires et s'engagent à les manipuler conformément à PCDSS. Il y a un certain nombre d'exigences qu'on ne va pas pouvoir externaliser. Effectivement, c'est un mythe de dire « j'utilise des prestataires qui sont certifiés PCDSS,

[00:02:57] donc je suis moi-même certifié PCDSS ». Ça ne marche pas comme ça. Il y a au moins certaines exigences qu'il convient de respecter. À ce propos, il n'y a toujours pas rien. J'avais dit que c'est un sujet dont je m'entends souvent parler dans mon job. Maintenant, je n'ai pas les détails sur quoi ça correspond. Quand on dit qu'un partenaire est certifié PCDSS, concrètement, ça veut dire quoi ? Je ne sais pas quoi tu fais allusion. La différence entre certification et conformité ? Non, en fait, je veux dire un partenaire qui est certifié PCDSS.

[00:03:27] Ça veut dire qu'eux-mêmes ont fait leur parcours de certification en tant que service provider ou merchant, par exemple. Est-ce qu'ils peuvent couvrir une partie de la PCDSS ? En gros, ce que je veux comprendre, c'est qu'il y a un partenaire qui est certifié PCDSS. Est-ce que ça veut dire qu'eux-mêmes sont certifiés par rapport à leur activité ? Ou alors, comment est-ce que toi, ça t'aide dans ta propre certif que le fait qu'eux soient certifiés ? Ça, j'ai envie de dire. OK.

[00:03:55] Effectivement, être certifié PCDSS, à l'imite, ça ne veut pas dire grand-chose. Ça dépend du périmètre en question. Ça dépend des exigences appliquées. Et on a exactement cette même problématique sur de l'ISO 27001, par exemple. Je suis certifié ISO 27001, ça ne veut pas dire grand-chose. On ne sait pas sur quel périmètre. On ne sait pas avec quel engagement sur les exigences de sécurité. PCDSS, pour en savoir davantage sur le périmètre ou sur les exigences qui ont été revues par un auditeur, ça va être de lui demander l'AOC, justement.

[00:04:25] Parce que dans l'AOC, dans les premiers chapitres, on va devoir décrire le périmètre, qu'est-ce qui a été audité, qu'est-ce qui a été mis hors périmètre. Et il y a une deuxième partie où on va lister les exigences qui n'ont pas été appliquées. Donc typiquement, on peut très bien avoir une entreprise qui va être certifiée PCDSS uniquement sur certains chapitres. Parce que, par exemple, on est sur du e-commerce et on s'appuie sur des PSP qui sont certifiés PCDSS. Et dans ce cas-là, on va être éligible à ce qu'on appelle le SAQA.

[00:04:54] Ça, c'est le PCI Council qui a identifié quelles étaient les à peu près 15 exigences les plus pertinentes par rapport au contexte du e-commerce quand on s'appuie sur des PSP qui sont certifiés PCDSS. Ou alors, ça peut être un prestataire qui va être certifié PCDSS sur l'entièreté des exigences. Donc effectivement, on peut avoir des différences en nombre d'exigences applicables dans une certification. De même que le périmètre ne sera pas forcément celui qui est escompté. On peut très bien imaginer un e-commerce, un site e-commerce,

[00:05:24] une entreprise e-commerce qui a deux sites de paiement, deux pages de paiement, une qui va être certifiée PCDSS et l'autre qui ne va pas l'être. Donc effectivement, c'est toujours important lorsqu'on est une entreprise et on décide de travailler avec une entreprise, un partenaire qui est certifié PCDSS, de bien vérifier le périmètre pour savoir est-ce que c'est bien celui qu'on souhaite qu'il soit certifié. D'accord. Donc en somme, ça veut dire que tous les partenaires certifiés PCDSS ne sont pas équivalents parce que le périmètre forcément est différent.

[00:05:54] Donc ils peuvent t'aider de manière externalisée sur certains aspects, mais pas forcément tous. Du coup, la question qui revient par rapport aux termes de pratique, au début, tu mentionnais pour l'audit la partie interview. Donc j'imagine que c'est une question bête, je suppose. Du coup, ça voudrait dire que demain, tu as une entreprise qui va utiliser un partenaire externe pour une partie de PCDSS parce qu'ils sont certifiés sur un périmètre X bien précis. Demain, tu fais une interview chez une entreprise qui va être certifiée.

[00:06:21] Une partie de la structure de leur parcours PCDSS est couverte via un partenaire. Donc forcément, j'imagine que je ne vais pas aller interviewer le partenaire. Tu vois, sûrement, j'imagine leur demander leur propre certif avec une notion de périmètre. Il faut bien confirmer que ce périmètre-ci est couvert à travers le partenaire, c'est ça ? Donc effectivement, il y a deux cas. Quand on audite une entreprise, il y a deux possibilités. Soit elle utilise des prestataires qui sont certifiés PCDSS, soit les prestataires ne sont pas certifiés PCDSS.

[00:06:49] Lorsque le prestataire en question n'est pas certifié PCDSS, là, effectivement, il va falloir que j'aille auditer le prestataire en question pour m'assurer qu'il respecte bien les exigences PCDSS. Lorsque l'entreprise en question, le prestataire en question est certifié PCDSS, je vais effectivement m'assurer qu'ils sont bien certifiés PCDSS. Un moyen de m'assurer qu'ils sont certifiés PCDSS, c'est d'avoir leur AOC. Et je ne vais pas m'arrêter là, bien sûr. Je vais regarder sur l'AOC, est-ce que le périmètre est cohérent

[00:07:19] avec ce qui m'a été dit ? Si, par exemple, l'entreprise en question utilise un prestataire sur la partie n'importe quoi, infogérance, et que lorsque je regarde sur l'AOC, c'est sur la partie, est-ce qu'ils ont des activités e-commerce aussi, c'est sur la partie e-commerce, bien sûr, ça ne sera pas recevable. Il faut que l'AOC, la description du périmètre dans l'AOC soit conforme avec l'externalisation. Donc ça, c'est un point que j'ai regardé. Et je vais également regarder aussi au niveau des exigences applicables. Parce qu'on peut très bien imaginer

[00:07:47] que le QSA du prestataire était choisi pour leur certification à eux, les a audités uniquement sur un chapitre, par exemple la partie antivirus. Or, pas de chance, l'entreprise en question que j'audite, eux vont externaliser la partie infogérance. Donc là, pareil, on aura une incohérence aussi entre les exigences qui ont été sélectionnées et l'exigence sur laquelle eux, ils sont certifiés. Le problème, c'est que j'ai 50 questions à te poser, mais le temps n'est pas illimité. Donc, je la garde de côté. Si tu veux, après, on pourra toujours faire un deuxième point.

[00:08:17] Ça me dérange vraiment pas. Ouais, ouais. Non, mais du coup, ce que je fais, je la garde de côté et après, j'y reviendrai si on a le temps. Pas de souci. Parce qu'en pré-prenant du podcast, tu me disais, il y a un point qui était important à faire ressortir. C'était que c'est pas uniquement un standard de sécurité pour la gestion des prestataires et surtout que c'est pas juste de la technique, tu me disais. Oui. Et du coup, la question ? Non, tu me disais de faire ressortir justement que c'est pas de la technique. Donc, en gros, qu'est-ce qui n'est pas juste de la technique ? Oui, oui. OK.

[00:08:47] Effectivement, il y a plein d'exigences sur... en relatif à la technique, un système, réseau, mise à jour, cryptographie, anti-malware, etc., etc. Ensuite, on a des exigences de sécurité physique. Par exemple, il faut avoir des caméras, il faut avoir du contrôle d'accès, il faut avoir des broyeurs. Lorsqu'on a des papiers avec de la donnée carte bancaire, effectivement, il faut prévoir de les détruire de manière sécurisée lorsqu'il n'y en a plus besoin. On a également des exigences juridiques. Donc ça, ça va être l'aspect gestion des prestataires. Avant de travailler

[00:09:17] avec un autre prestataire, il faut avoir des process pour ça. Par exemple, il faut avoir des due diligence, il faut s'assurer que le prestataire en question ait peut-être certifié PCDSS en amont ou à d'autres certifications. Dans la partie contractuelle, il faut prévoir aussi qu'il va bien s'engager sur le maintien, sur la sécurisation des données cartes qu'on va lui confier, ou qu'il va s'engager à ne pas faire n'importe quoi sur notre périmètre. Donc ça, c'est sur la partie juridique. On a également des exigences plutôt sur la partie ressources humaines

[00:09:46] que sur la partie recrutement. Avant de recruter une personne qui va travailler sur un périmètre PCDSS, il va falloir faire du screening. Donc on va enquêter par exemple auprès de son employeur précédent. On va lui demander éventuellement son extrait de quasi-judicière B3 pour s'assurer qu'il n'a pas fait de la fraude interne par exemple dans une autre entreprise. Et ça, c'est à faire avant effectivement de recruter la personne. On a également de la partie gouvernance donc sensibilisation annuelle, formation des développeurs, PSSI,

[00:10:16] gestion des incidents, etc. Effectivement, c'est faux quand même et ça, c'est aussi un mythe de dire que PCDSS, ça ne se résume que de la technique parce qu'effectivement il y en a beaucoup mais en tout cas, ce n'est pas que de la technique. Du coup, en faisant un peu une vue sur le parcours pour obtenir un certif, déjà la première étape c'était comment se remettre en conformité. Si tu peux étendre dessus justement de manière générale, quelles sont les étapes ou je ne sais pas comment procéder pour se mettre en conformité ? Oui.

[00:10:45] Pour se mettre en conformité, effectivement, il y a toujours plusieurs approches à faire. La première question déjà à se poser, c'est pourquoi on a besoin de se mettre en conformité ? Oui. Est-ce que c'est la banque acquéreur qui va nous le demander ? Est-ce que ça va être les schemes ? Est-ce qu'on est mal renseigné et on pense parce qu'on voit passer du numéro de carte bancaire qu'on est éligible à PCSS ? Pour rappel, PCSS, ce n'est absolument pas une contrainte réglementaire mais c'est une contrainte contractuelle. Déjà,

[00:11:14] ce qu'il y a à avoir à l'esprit, ce qui est important de voir à l'esprit, c'est qui est notre demandeur ? Parce que potentiellement, on peut avoir des questions sur lesquelles ça va être compliqué de trancher, donc il faudra voir avec celui-ci pour qu'il puisse nous éclairer. Ensuite, la deuxième question à se poser, c'est quel est le périmètre de certification ? Ça, c'est vraiment important. Là, on va rejoindre la notion de CDE. On va faire un schéma, typiquement un schéma réseau. Sur le schéma réseau, on va chercher à comprendre par où passe le numéro de carte bancaire. Par exemple, on est un site e-commerce, on va être connecté à Internet,

[00:11:44] la page de paiement va être connecté à Internet. C'est donc la page de paiement qui va recevoir le numéro de carte bancaire. Ensuite, ça va passer par d'autres serveurs potentiellement, par la base de données parce qu'on va aller requêter la base de données, etc. Ça, ça va permettre d'identifier le CDE qui est vraiment la première bulle PCDSS. Ensuite, on va avoir une deuxième bulle. Ça va être l'ensemble des serveurs qui peuvent impacter la sécurité de la première bulle. Ça, c'est ce qu'on va appeler par exemple le Connected to CDE. Ça, c'est important aussi d'avoir l'entièreté des composants

[00:12:14] Connected to CDE pour connaître quels sont les composants qui doivent respecter l'exigence PCDSS. Parce qu'une des stratégies lorsqu'on va être dans un projet de conformité à PCDSS, ça va être de minimiser le périmètre de certification. Forcément, s'il faut respecter les 250 exigences PCDSS, ça peut coûter cher. Un moyen de diminuer le périmètre de certification, ça va être par exemple d'utiliser de la tokenisation. Tokenisation, ça va être, on remplace le numéro de carte bancaire

[00:12:43] par une donnée et ce processus est réversible mais uniquement par ceux qui ont la connaissance. Tous les personnes, tous les serveurs qui vont voir passer le token seront en incapacité de récupérer le numéro de carte originelle et donc ça, ça va permettre de justifier l'exclusion des autres serveurs qui vont recevoir le token. Ça, c'est le troisième point, ça va être vraiment la définition du périmètre. Ensuite, il va falloir faire une analyse des cas, un gap analysis. Ça, idéalement,

[00:13:13] on conseille que ça soit fait par une personne qui est indépendante, même si ce n'est pas une obligation. Ça veut dire qu'on va prendre une photo du périmètre et on va le comparer par rapport au standard et on va évaluer les exigences qui sont conformes, celles qui ne sont pas conformes. Pour celles qui ne sont pas conformes, il va falloir mettre en place un plan d'action et ensuite, ça va permettre effectivement de mettre en place un projet de conformité. Donc, qu'est-ce qu'on doit mettre en place pour être conforme et le jour où on est conforme, même avant idéalement, choisir une entité pour se faire auditer, prévoir l'audit.

[00:13:43] Effectivement, il y a plusieurs points à mettre en place avant de se faire certifier. Et donc ça, c'est toujours bien quand même de se faire accompagner, sauf si on connaît bien le standard, mais c'est toujours bien effectivement de prendre une personne qui est qualifiée sur PCDSS pour faire déjà l'analyse des cas, pour être pragmatique et minimiser la taille du périmètre PCDSS et derrière, de faire la certification. Oui. Et dans la partie précédente, tu en as un petit peu parlé déjà,

[00:14:13] mais on va dire entre guillemets seconde étape, seconde partie, qui est comment obtenir la certification, comment ça se déroule. Au début, tu parlais d'interview ou ce genre de choses, c'est quoi un peu le process, à quoi ça ressemble. On va dire, admettons, ça veut dire en gros, tu es prêt à pousser ton dossier de candidature, presque pour la norme. Maintenant, l'auditeur va te contacter, comment ça se déroule ? Oui. Donc, à partir du moment, effectivement, c'est à partir du moment où l'entreprise a choisi son entreprise QSA, on va se mettre en mode projet. Donc,

[00:14:43] on va faire un kick-off pour lancer officiellement la mission. On va comprendre le périmètre PCDSS, on va chercher à le définir correctement. On va identifier quelles sont les personnes qu'on va devoir interviewer. On va identifier les exigences qui sont concernées par PCDSS. On va ensuite expliquer, on va définir ensemble les dates d'intervention. Donc, par exemple, visite sur site, interview, etc. Ça, ça va être la première étape, ça va être le kick-off. Ça va être pour décrire tout l'aspect logistique de la certification. Ensuite,

[00:15:12] il va y avoir deux autres étapes. La première étape, ça va être la revue documentaire. C'est-à-dire qu'en amont, on va lui envoyer au client une liste des documents qui sont demandés par PCDSS. De l'autre côté, ça va nous permettre de regarder est-ce que les documents respectent les exigences documentaires PCDSS. Ensuite, on va avoir la phase d'audit. On va aller sur site, on va aller s'assurer du respect des exigences de sécurité physique. On va aussi observer, par exemple, sur la partie cryptographie, en cas de génération de clé,

[00:15:42] est-ce que c'est bien conforme à PCDSS ? Il va y avoir la partie interview aussi. On va aller poser plein de questions aux clients pour s'assurer qu'ils ont bien connaissance du standard. Et on va aussi lui demander de se connecter lorsque c'est applicable, bien sûr, sur le système, par exemple, pour s'assurer qu'effectivement, ce qu'il nous a dit était bien cohérent. Et donc ça, effectivement, en fonction de la taille du périmètre, l'auditeur ne va pas pouvoir tout contrôler. Effectivement, parfois, on a plus de 1000 serveurs dans un périmètre PCDSS

[00:16:11] et donc l'auditeur va faire de l'échantillonnage. Donc, il va les contrôler, par exemple, tel serveur parce qu'il considère qu'il est plus critique qu'un autre. Il va les contrôler un autre serveur sur un autre site parce qu'ils sont en data center, il y a deux data centers pour effectivement assurer de la haute résilience. Et donc, un coup, on va auditer des serveurs sur le premier data center et un coup, des serveurs sur le deuxième data center de sorte à avoir un échantillon représentatif du système du périmètre de certification. Donc là, si je n'ai pas l'étape, on est d'accord.

[00:16:41] Maintenant, tu veux les certifier ? Oui. Forcément, ce n'est pas la vie, on est d'accord. Il y a une partie renouvellement. Dans la précédente partie, tu parlais, tu sais, j'ai pris mes notes, tu parlais, qu'est-ce que j'avais marqué ? Les quatre occurrences de scan tous les trois mois. Donc, je pense que ça, c'est une des exigences PCDSS. Des exigences. Oui. Parce qu'en temps des recherches, je les ai sur un site, une citation d'un client qui disait « Obtenir PCDSS en tant que processeur

[00:17:10] pour le compte de Visa est un enjeu stratégique et commercial. Préserver cette certification est un enjeu organisationnel. » Donc, forcément, c'est sûr que c'est comme tout. Le fait de l'obtenir, c'est bien. Mais après, le fait de la maintenir pour ton business, c'est aussi important. Donc, concrètement, tu peux étendre un petit peu sur la partie renouvellement ? Effectivement, à l'étape d'avant, on a vu le projet de mise en conformité ou de manière plus générale, l'audit. Une fois qu'on est certifié PCDSS, on s'engage, l'entité en question s'engage à respecter

[00:17:39] les procédures qui ont été définies. Parmi ces procédures, il va être demandé de faire un test d'intrusion annuel, interne, un test d'intrusion externe, annuel, des scans de vulnérabilité interne, trimestriel, des scans de vulnérabilité externe, ASV, qui est une autre abréviation pour un peu mal employé. Donc, c'est une entité qui est qualifiée par le PCI-CUNCIL à faire des tests, des scans de vulnérabilité externe, la mise à jour annuelle de la PSSI, etc. Lorsqu'on va procéder au renouvellement de la certification,

[00:18:09] l'auditeur va non seulement s'assurer que les exigences de sécurité sont conformes au moment de l'audit, mais il va également s'assurer que sur l'année écoulée, toutes les exigences, toutes les procédures ont été respectées avec les périodicités définies. Et donc, effectivement, ça veut dire quoi ? Ça veut dire que l'entité doit mettre en place l'organisation adéquate pour faire en sorte que les personnes, que les procès sont bien effectués régulièrement. Typiquement, il y a une exigence

[00:18:39] PCI-DCS qui demande de mettre un rôle périodique, par exemple, pour s'assurer que toutes les procédures sont bien effectuées régulièrement. L'exigence en question donne quelques exemples. Elle n'est absolument pas exhaustive. En tout cas, si on veut minimiser le risque de ne pas être certifié, effectivement, on a intérêt à blinder la partie contrôle périodique. Oui. En faisant des recherches, j'avais aussi deux points et du coup, je voulais avoir ton opinion dessus. Déjà, le premier point, c'était,

[00:19:09] il disait, donc là, je lis la phrase, il disait l'obtention de la certification PCI-DCS est un défi car il faut ton capacité de trouver un juste milieu entre le niveau de sécurité requis par la norme et le niveau de sécurité cohérent avec ses activités tout en ne perturbant pas la productivité. Oui. Alors, ça, c'est compliqué, on va dire. Pas forcément compliqué, mais ça va être trouver le juste milieu entre l'entité en question et l'auditeur. Attends, parce qu'il y a une question d'assurance aussi

[00:19:38] en cas de non-respect de la certification PCI-DSS, si jamais le client venait à se faire compromettre, il pourrait être reproché à l'auditeur d'avoir été un peu trop laxiste et d'avoir signé les yeux fermés. Donc, effectivement, il faut trouver un juste milieu qui conforte, on va dire, la situation de l'auditeur, mais également qui ne soit pas trop compliqué à implémenter pour l'entité en question. PCI-DSS, c'est plutôt bien fait, donc généralement, il n'y a pas trop d'ambiguïté. Effectivement, parfois,

[00:20:07] il faut réadapter l'exigence pour la rendre cohérente par rapport à l'exigence et c'est notamment l'une des approches qui est intéressante avec PCI-DSS, V4, ça va être la possibilité, la flexibilité offerte aux entités de répondre à une exigence de manière différente. Oui, c'est-à-dire ? C'est-à-dire que, par exemple, PCI-DSS, V4 va demander d'implémenter telle exigence, l'entité en question va dire, bah ouais, mais nous, on ne peut pas le faire comme ça parce qu'on ne fonctionne pas de cette manière, en plus, ça ne nous paraît pas cohérent

[00:20:37] par rapport à notre mode de fonctionnement, est-ce qu'on ne pourrait pas y répondre de manière différente ? Et PCI-DSS, V4 autorise cette approche-là, c'est ce qu'on appelle l'approche personnalisée. Dans ce cas-là, l'entité en question va devoir mettre en place une analyse de risque ciblée, donc à partir de l'objectif de l'exigence. Pourquoi l'exigence, elle demande ça ? C'est pour répondre à un objectif bien précis. Ensuite, qu'est-ce que l'entité en question décide de mettre en place ? Avec une justification, pourquoi les mesures de sécurité qu'elle souhaite mettre en place répondent

[00:21:07] à l'objectif de sécurité ? Et ensuite, le QSA, donc l'auditeur, va décliner ces mesures de sécurité après les avoir approuvées, bien évidemment, en procédure de test pour le jour de l'audit, savoir précisément comment contrôler que l'entreprise en question a respecté l'exigence. Là, tu parlais, et du coup, c'est marrant, parce que du coup, j'ai pu poser la question que j'avais initialement mis de côté au début. Là, tu parlais d'assurance, donc responsabilité. Et ça me faisait penser un peu au début

[00:21:36] de cette partie-ci. Tu me clarifies ces histoires de partenaires qui disent qu'ils sont certifiés PCI DSS. Donc, admettons, moi, je suis l'auditeur, d'accord ? L'entreprise qui veut la passer. Et je dis, je vais externaliser ces trois chapitres chez un partenaire. Maintenant, la question, c'est au niveau de la responsabilité. Quelle est ma responsabilité ? Moi, en tant qu'entreprise qui a utilisé un partenaire externe, justement sur un périmètre sur lequel je n'ai pas la main, concrètement. Oui. Alors déjà, ce qu'il faut savoir aussi, c'est le jour où il y a une compromission

[00:22:05] de carte bancaire, il va y avoir les schemes en question Visa, Mastercard, vont demander à ce qu'il y a une enquête. Donc, ça va être du forensic qui va être effectué pour savoir qu'est-ce qui s'est passé, pourquoi il y a eu une fraude, c'est de la responsabilité de qui ? Est-ce que c'est de la responsabilité de l'auditeur qui a signé sans avoir contrôlé ? Est-ce que c'est de la responsabilité de l'entreprise qui s'est fait auditer ? Par exemple, au moment de la certification, ils étaient bons,

[00:22:35] mais une fois que l'auditeur est parti, on a enlevé le niveau de sécurité en question. En fonction de ça, effectivement, les assurances vont prendre la relève et dire c'est à moi de payer ou c'est à lui de payer. Lorsque l'exigence de sécurité, ça va être de la responsabilité du prestataire, ça va dépendre est-ce que le prestataire était certifié PCDSS ou pas ? On va se reposer les mêmes questions. S'il était certifié PCDSS, pourquoi cette fraude a été permise ? Est-ce que c'est leur QSA qui a été

[00:23:05] et qui a signé les yeux fermés ou est-ce que c'est l'entreprise en question qui a downgradé leur niveau de sécurité après le passage du QSA ? En fonction de ça, on saura qu'il va devoir mettre la main au portefeuille. Si le prestataire n'est pas certifié PCDSS, là effectivement, à mon sens en tout cas, ça va être au niveau contractuel, ça va se jouer. Soit l'entreprise en question a prévu dans les clauses du contrat qu'en cas de fraude, effectivement, ça serait reversé au prestataire dans ce cas-là,

[00:23:34] c'est le prestataire qui va devoir payer. Soit rien n'était prévu et ça va être de la responsabilité de l'entreprise parce que l'entreprise est quand même responsable de ses prestataires au-dessus de la loi et donc c'est elle qui va devoir payer. Oui, il y a aussi une seconde problématique, enfin problématique, quand j'ai fait des recherches ils appellent ça problématique, c'est autant de me dire mais a priori ça semble comme une problématique. Non mais eux disaient, il y a un coup je vais lire, ils disaient il faut savoir fédérer ses équipes tout en ayant la capacité de fournir un état des lieux de la conformité

[00:24:04] à la hiérarchie et il faut savoir s'organiser pour pouvoir maintenir la conformité dans le temps tout en assurant un bon système de contrôle continu des mesures mises en place. Oui, effectivement et ça, ça découle de tout ce qu'on a dit juste avant c'est que PCDSS ce n'est pas que de la technique donc ça veut dire qu'il n'y a pas que la DSI qui va être concernée par la certification on va avoir également le RSSI parce qu'il faut que la PSSI soit maintenue à jour il faut également embarquer dans le périmètre de certification les RH parce que les RH

[00:24:32] il va falloir qu'ils procèdent au screening le juriste de la société pour s'assurer effectivement que les contrats ont bien été revus la direction générale c'est un petit cas particulier mais globalement si la direction générale les postes engagés ça va être compliqué de maintenir le niveau de sécurité globalement tous les acteurs de la société ou en tout cas une bonne partie est engagée dans la certification PCDSS et effectivement s'il y en a qui n'ont pas envie de se mettre en ordre de bataille ça va être compliqué de maintenir

[00:25:02] le niveau de certification donc effectivement c'est important d'avoir un vrai sponsor en interne pour mobiliser toutes les équipes toutes les structures de la société pour maintenir la certification PCDSS ouais peut-être aussi avant je vais finaliser cette partie ici tu me disais qu'il y avait 16 sur le PCI console il y en avait 16 PCI 16 différents types de certifs on va peut-être éventuellement faire un petit point sur ça et aussi est-ce qu'il y a des c'est peut-être une question bête mais j'imagine que forcément

[00:25:32] certaines exigences doivent se croiser pour d'autres normes PCI j'imagine en somme ça veut dire que sûrement obtenir la PCDSS il y a sûrement des choses qui vont te permettre d'obtenir d'autres certifs PCI sur d'autres aspects dont tu aurais besoin ou pas oui c'est plutôt le contraire en fait dans le sens que PCDSS c'est vraiment une certification d'environnement et c'est plutôt les autres standards de sécurité globalement de l'écosystème PCI qui vont aider à l'obtention de la certification

[00:26:02] PCDSS je m'explique dans l'écosystème PCI il y a donc 15 standards de sécurité on va avoir des standards de sécurité sur des appareils par exemple les terminaux de paiement les HSM donc ça ça va être la famille des PCI PTS on va avoir des standards qui vont concerner les solutions par exemple le P2PE donc Point to Point Description c'est une solution qui va permettre de chiffrer le flux du terminal de paiement par exemple jusqu'au prestataire

[00:26:31] permettant aux commerçants de ne pas avoir passé le donné carte et donc d'être un peu moins concerné on va dire par PCDSS même s'il le restera par rapport à ce que j'ai dit avant on va avoir des standards de sécurité sur des applications de paiement et sur leurs éditeurs donc ça ça va être par exemple le framework PCI SSF et enfin on va avoir des standards de sécurité pour les environnements PCI DSS dont l'objectif est de sécuriser la donnée carte bancaire on va avoir aussi le PCI PIN où là l'objectif ça va être de s'assurer

[00:27:00] que le code confidentiel qu'on saisit pour valider une transaction sur un terminal de paiement est bien traité de manière sécurisée et donc globalement toutes les exigences tous les autres standards de sécurité le SSF donc sur les applications sur les appareils PCI PTS etc lorsqu'on va être conforme sur ces exigences là une entreprise qui souhaite être certifiée PCI DSS utilise des solutions qui sont déjà certifiées ça va permettre à l'auditeur de se baser sur ces certifications

[00:27:30] et de cocher la case de l'exigence en question dans le référentiel PCI DSS par exemple si dans PCI DSS on dit il faut que l'application de paiement coadurcit qu'elle ne contienne pas de vulnérabilité non plus effectivement si l'application de paiement est déjà certifiée PCI SSF effectivement l'auditeur en question va pouvoir s'appuyer sur cette certification le fait d'être certifié sur ces produits et solutions ça aide toujours l'éditeur ça aide toujours

[00:28:00] l'entité en question à se faire certifier PCI DSS d'accord donc en somme si je comprends bien la PCI DSS c'est presque entre guillemets la master certification PCI et le reste c'est des choses plus spécifiques comme tu mentionnais la pin etc des points peut-être plus spécifiques genre des modules on va dire précis qui complètent ensuite après la PCI DSS et bien j'irais même plus loin en disant que ce n'est pas entre guillemets c'est exactement ça d'accord vraiment ça

[00:28:30] c'est vraiment je voulais pas dire n'importe quoi des fois non mais c'est exactement ça PCI DSS c'est vraiment la pierre angulaire qui permet à tous les standards d'avoir un lien logique tous les standards ont un lien logique dans le sens qui permettent effectivement de simplifier les certifications PCI DSS globalement c'est vraiment la pierre angulaire d'accord on va finiser le podcast et on a dépassé le temps déjà désolé je ne te souviens quel est le mot de clôture du podcast pour toi alors le mot de clôture c'est effectivement que

[00:28:58] la certification PCI DSS déjà elle n'est pas obligatoire en point de vue réglementaire pour autant dès lors qu'on manipule des données de carte bancaire c'est important que ça soit fait de manière sécurisée pour éviter justement la fuite de données cartes comme on voit un peu trop souvent malheureusement dans la nature et derrière il y a une notion de confiance parce que le jour où les personnes n'ont plus confiance de vouloir payer sur un site parce qu'il y a eu de la fuite de données cartes ça va commencer à être compliqué de réinstaurer la confiance donc effectivement dès lors qu'on manipule

[00:29:28] des données cartes effectivement c'est bien au moins de faire une première analyse des cartes pour voir son niveau de conformité avec PCI DSS son niveau du respect des exigences et c'est également important aussi d'avoir à l'esprit qu'être certifié PCI DSS ce n'est pas suffisant c'est pas qu'on est certifié PCI DSS qu'on est hyper sécurisé et qu'on risque rien PCI DSS c'est un standard de sécurité qui a été écrit déjà par les schemes pour protéger les données cartes

[00:29:58] c'est tout donc s'il y a des données personnelles qui passent par là PCI DSS ne va pas dire grand chose ce n'est pas son problème PCI DSS ça concerne également une infime partie de son environnement toute la société n'est absolument pas concernée par PCI DSS uniquement la partie qui voit passer des données cartes bancaires donc c'est vraiment très très important d'avoir ça à l'esprit et de ne pas se dire c'est bon je suis certifié PCI DSS je suis sécurisé ça peut être bien de compléter ça par d'autres certifications de sécurité il y a un point peut-être que c'est moi qui ai mal compris

[00:30:28] tu m'excuses si j'ai mal compris tu l'as dit au début tu m'excuses je ne sais pas c'est moi qui ai mal noté mes notes que du coup ce n'est pas une exigence réglementaire parce que j'aurais pensé que si tu en gros si tu proposes des services de paiement à travers ton activité de e-commerce ou peu importe pour un e-commerce par exemple j'aurais pensé que c'était une exigence réglementaire et qu'il te fallait absolument avoir la PCI DSS pour faire ton business et je pose la question parce que moi demain je suis utilisateur

[00:30:58] j'achète sur un site d'e-commerce je ne vais pas aller vérifier s'ils sont certifiés donc en fait comment ça fonctionne est-ce que c'est moi qui ai mal compris ce que tu voulais dire ? Non non tu n'as pas mal compris effectivement ce n'est pas une exigence réglementaire dans le sens qu'il n'y a pas dans le code monétaire et financier par exemple un article qui dit toute entreprise qui voit passer de la donnée carte doit être certifiée PCI DSS ça ça n'existe pas il s'agit vraiment d'une exigence contractuelle donc ça peut être par exemple lorsqu'un service provider

[00:31:28] qui est interconnecté au scheme Visa Mastercard par exemple Visa et Mastercard peuvent leur demander en contrepartie d'être certifié PCI DSS et chaque année ils vont leur demander leur AOC ça peut être également quand on est un commerçant la banque acquéreur qui va lui demander en retour d'être certifié PCI DSS mais ça encore une fois vu que l'acquéreur va être responsable du programme de conformité c'est elle qui va choisir les commerçants qui ont besoin d'être certifié PCI DSS bien sûr la boulangerie du coin qui voit passer parce qu'elle est dans

[00:31:56] un petit village voit passer 5 personnes effectivement on ne va pas lui demander de se mettre en conformité à PCI DSS en revanche le site e-commerce qui a pignon sur rue qui voit passer plusieurs millions de transactions là effectivement le risque est très très élevé et dans ce cas là la banque acquéreur va lui demander de se mettre en conformité à PCI DSS et même d'être certifié donc vraiment c'est une appréciation des risques mais en tout cas oui effectivement ce n'est pas une obligation réglementaire tout à fait appréciation des risques d'accord écoute je vais arrêter l'enregistrement

[00:32:26] dans 2 secondes après je te propose un débrief en tout cas je te remercie d'avoir pris le temps et comme toujours dans mes podcasts souvent je parle avec l'invité c'est rare que les podcasts se fassent très rapidement ça fait quelques temps on n'en avait pas on n'avait pas envie de faire le podcast donc je te remercie d'avoir pris le temps pour parler du sujet avec plaisir j'espère que cet épisode vous a plu si vous n'avez pas écouté la première partie de notre échange sachez qu'il est disponible dans l'épisode précédent si vous avez aimé le contenu s'il vous plaît

[00:32:55] mettez un bon avis soit directement sur mon site cybersécuritéod.fr dans la partie avis des auditeurs ou directement sur Apple Podcast déjà un pour moi ça fait super plaisir de lire vos avis positifs et en plus ça permet de faire grandir le podcast je vous remercie et passez une bonne semaine à la fin

Kévin DEJOUR

A participé à

PCI DSS - Les mythes & le parcours d’obtention | #62

Échange avec un ancien RSSI. Aujourd'hui auditeur PCI DSS (QSA) | #61