Vous êtes-vous déjà senti frustré au sujet de la conformité en matière de sécurité ? Vous n’êtes pas le seul. Nous avons tous une sorte de « Kryptonite » lorsqu’il s’agit de conformité. J’ai demandé à certains de nos auditeurs InfoSec de partager leur Kryptonite. Leurs réponses se sont concentrées sur la douleur du jour, les nouvelles versions 4.0 et 4.01 de la norme PCI DSS. Alors, cher lecteur, entrons dans le vif du sujet.
La première réponse est Chris CamejoResponsable de la pratique de la conformité :
Jamais demandé
« Ma kryptonite en matière de conformité, c’est lorsqu’une organisation demande pourquoi nous l’obligeons à faire quelque chose pour la conformité qu’elle n’a jamais eu à faire auparavant. Il s’agit souvent de contrôles de sécurité qui ont été approuvés par les précédents auditeurs. Cela me pousse à remettre en question ma compréhension du cadre (et parfois ma santé mentale). Dire « tous les autres auditeurs à qui vous avez parlé ont tort » me semble égoïste, alors je retourne souvent à la source pour vérifier ma compréhension, mais je me retrouve généralement face à une exigence assez claire, soutenue par des documents d’orientation et des FAQ qui contiennent souvent des exemples spécifiques pertinents ».
« Après de nombreuses années, je suis arrivé à la conclusion que certains auditeurs tombent dans le même piège que les organisations qu’ils évaluent : Ils font des suppositions sur la signification d’une exigence sans vraiment la comprendre dans son contexte ou sans consulter des orientations supplémentaires (je déteste dire cela, mais j’ai probablement été ce type au début de ma carrière dans le domaine de la conformité). Cela ne rend pas service aux organisations évaluées, car elles sont confrontées à des surprises soudaines lors de l’audit si un nouvel auditeur a une meilleure compréhension des exigences que l’auditeur précédent. Parfois, cela fonctionne aussi dans l’autre sens. Je trouve des organisations qui font des choses qui ne sont pas requises ‘à des fins de conformité’ en raison d’une mauvaise lecture des exigences ».
Depuis le début
« Il y a toujours eu des idées fausses sur la façon dont PCI DSS (et d’autres cadres de conformité) définissent leur champ d’application et ce qui est acceptable pour certaines exigences. Bon nombre de ces idées fausses ont été abordées dans divers documents d’orientation et FAQ que personne, à l’exception des experts en conformité les plus dévoués, n’a pris le temps de lire et de comprendre. Je considère que bon nombre des « changements » de la version 4.0 de la norme PCI DSS tirent les informations des documents d’orientation et des FAQ vers la norme elle-même, consolidant ainsi ce qui a toujours été attendu en un seul endroit où il y a plus de chances de le voir. L’organigramme du champ d’application ajouté à la section 4 de la norme PCI DSS en est un exemple. Il a permis à de nombreuses organisations de mieux comprendre ce qui est compris dans le champ d’application et ce qui en est exclu. Le secret est que cet organigramme se cachait depuis des années dans le document PCI Scope and Segmentation Guidance, où très peu de gens l’ont remarqué, et ce n’est que maintenant qu’il a été intégré dans la norme DSS elle-même.
Nouveau pour vous
« J’ai vu un certain nombre de clients accuser les changements d’être nécessaires pour s’aligner sur la nouvelle version 4.0 de la norme PCI DSS, alors que le résultat du changement est quelque chose qu’ils auraient dû faire depuis le début. D’une part, cela signifie que les changements sont efficaces : ils forcent les organisations à converger vers une compréhension unique et cohérente du champ d’application et des exigences de la norme PCI DSS, au lieu que certaines organisations s’en tirent avec des économies de bouts de chandelle. D’autre part, en tant que consultant, il est pénible de devoir dire à un client qu’il s’est trompé et qu’il doit repenser sa façon d’aborder la conformité.
J’ai été piégé
« En tant que chef de pratique, je suis souvent impliqué dans l’ingénierie avant-vente, aidant à définir les engagements de conformité pour nos clients potentiels. J’ai régulièrement affaire à des organisations qui se démènent parce que la conformité à un cadre spécifique est exigée contractuellement par l’un de leurs partenaires ou clients. Très souvent, je me retrouve à essayer d’expliquer que le cadre de conformité ne s’applique pas à leur organisation pour une raison ou une autre. C’est souvent parce que l’organisation ne traite pas le type d’informations auquel le cadre s’applique, ou parce que l’organisation n’est pas dans le type d’activité auquel le cadre s’applique. La vraie raison est que le partenaire ou le client qui demande à l’organisation de se mettre en conformité ne comprend pas ce que sont les cadres de conformité eux-mêmes et pose les mauvaises questions. Après avoir répondu à un trop grand nombre d’appels de ce type, j’ai rédigé un article expliquant l’applicabilité des cadres qui sont souvent appliqués de manière inappropriée. »
Fournisseurs de services
« Conformément à l’exigence PCI 12.8.5, les commerçants doivent documenter les responsabilités des prestataires de services, mais il a toujours été difficile d’obtenir ces informations de la part des prestataires de services. La nouvelle exigence 12.9.2 devrait faciliter les choses, car les fournisseurs de services sont désormais tenus par la norme PCI DSS d’aider leurs clients à comprendre leurs responsabilités. Mais il y a un hic : Certaines grandes organisations publient des matrices de responsabilité qui laissent plus de questions que de réponses (par exemple, dans la matrice de Microsoft Azure, toutes les sous-exigences x.1.1 et x.1.2 sont marquées comme relevant de la seule responsabilité du client, même pour les exigences pour lesquelles Microsoft a revendiqué une responsabilité partagée ou unique pour d’autres sous-exigences). Si Microsoft est responsable de certaines sous-exigences, il doit également être responsable de ses propres politiques, procédures et attributions de rôles pour ces responsabilités, conformément aux sous-exigences x.1.1 et x.1.2. Les fournisseurs de services ont un long chemin à parcourir pour aider leurs clients à comprendre précisément quelles sont leurs responsabilités.
Chris avait beaucoup à dire !
A suivre Lee QuintonLee Quinton, un autre PCI QSA de longue date, travaille au Royaume-Uni.
Traîner les pieds
« Pour répondre plus précisément au dernier point soulevé par Chris, ils se heurtent également au fait que leur conformité est requise dans les deux ou trois mois à venir, alors que le fournisseur de services tiers PCI (TPSP) n’a pas besoin de se conformer avant six à neuf mois, et qu’il ne dispose d’aucune sorte de matrice de responsabilité développée pour aider son client à se conformer à l’exigence 12.8.5. »
Tous les QSA que j’ai interrogés se sont fait l’écho du problème posé par l’exigence PCI 12.8.5.
Le prochain article est Linus Garin, PCI QSA. Bien qu’il soit le plus jeune et le plus récent QSA de TrustedSec, il a accumulé de l’expérience dans plusieurs cadres et secteurs d’activité.
S’agit-il d’un MAP ?
« J’éprouve également des difficultés similaires en ce qui concerne les exigences 12.8 et 12.9. J’aide Chris à créer une matrice des responsabilités des TPSP pour un client et c’est BRUTAL. Cartographier les responsabilités de chaque TPSP ressemble à un jeu de devinettes, en particulier lorsque les TPSP ne fournissent pas une version de leurs responsabilités ou un AOC (soit qu’ils n’en aient pas, soit que le client soit incapable de les collecter pour une raison quelconque). Et pour les TPSP qui ont leur propre matrice de responsabilités, comme Azure et Cloudflare, comme Chris l’a dit, il y a des divergences dans la matrice qui créent plus de questions que de réponses. Il y a des contrôles qui sont marqués comme non applicables pour le TPSP alors qu’ils devraient clairement l’être, comme le 12.10 stuff. Dois-je suivre leur matrice de responsabilité ou utiliser le « jugement et l’interprétation du QSA » pour passer outre leur matrice de responsabilité ? »
« Ainsi, le client se retrouve avec un TPSP qui dit une chose et un QSA qui en dit une autre, ce qui n’est pas bon pour son expérience (et la nôtre). »
Le suivant est l’illustre auteur et QSA, Arthur Cooper (Coop).
Rester à la page
« Vous avez raison, Monsieur. À mon humble avis, cette question des TPSP a été la PIRE partie de mon temps en tant que QSA ».
Coop cherche également à obtenir une résolution rapide des normes de sécurité de l’industrie avec PCI. Par exemple, de nombreux dispositifs de paiement POS/POI actuellement approuvés utilisent le Triple Data Encryption Standard (3DES) dans le cadre du schéma Derived Unique Key Per Transaction (DUKPT), mais à partir du 31 décembre 2023, le National Institute of Standards and Technology (NIST) a déprécié ce schéma et conseillé aux organisations de l’abandonner en raison de problèmes de sécurité et de la disponibilité d’algorithmes de cryptage plus robustes.
En tant qu’auteur original de l’exigence 10 de la norme PCI DSS lorsqu’il siégeait au Conseil PCI, Coop demande fréquemment au Conseil actuel de clarifier divers aspects de la norme.
Le prochain article est Steph SaundersSteph Saunders, PCI QSA et spécialiste de longue date de la mise en œuvre de la sécurité. Elle a soutenu les contrôles de sécurité dans l’ensemble de l’entreprise et constate que de nombreuses entreprises sont confrontées à de nombreux défis en ce qui concerne la couverture globale et la configuration cohérente de l’IAM, en particulier avec le MFA à l’heure actuelle.
Identifiez-vous
« Pour les entreprises qui ont traversé plusieurs cycles d’innovation technique, de nombreuses configurations IAM ne sont tout simplement pas compatibles ni centralisées. Les différences techniques mises à part, la gestion décentralisée signifie aussi souvent que la désactivation des comptes de manière opportune, cohérente ou transparente est complètement différente d’un système à l’autre. »
« De nombreuses normes de conformité telles que PCI ne sont pas très prescriptives sur la manière de configurer correctement l’AMF (par exemple, les meilleures pratiques pour empêcher la réutilisation des jetons). De nombreuses normes telles que PCI n’incluent pas encore l’authentification sans mot de passe acceptable, malgré les nombreuses options existantes. »
La prochaine porte dérobée de l’utilitaire XZ
« Avec la nouvelle exigence PCI 6.3.2 qui demande un inventaire de tous les logiciels sur mesure et personnalisés, jusqu’où doit-on aller ? Par exemple, jusqu’à quel niveau de détail une entreprise doit-elle inventorier et gérer les bibliothèques open source ? Qu’en est-il des bibliothèques appelées par ces bibliothèques ? Pourquoi ne pas aller jusqu’à cinq niveaux de profondeur et avec quel niveau d’assurance ? De nombreuses entreprises ne savent pas où doit s’arrêter la diligence ».
Quel degré de diligence aurait aurait permis d’éviter l’attaque de la porte dérobée de l’utilitaire XZ?
« De nombreuses entreprises ne savent pas lesquels de leurs fournisseurs de services sont concernés par la conformité. Très souvent, les fabricants de systèmes d’exploitation (par exemple, Microsoft) et de dispositifs de réseau (par exemple, Cisco) sont traités comme des fournisseurs de produits de base et non comme des fournisseurs de services. Mais si ces mêmes fournisseurs ne fournissent pas de mises à jour en temps voulu, ils peuvent encore être le point faible de la prochaine plage de données. Jusqu’où doit aller la diligence raisonnable ?
Le suivant est votre blogueur, Steve Maxwell, un PCI QSA parmi d’autres normes.
Quoi, ces vieux chiffons ?
Quelle est ma plus grande kryptonite en matière de conformité ? Comme d’autres l’ont dit, c’est le défi que représente le suivi de la couverture de la sécurité par les prestataires de services de transfert de technologie. Les fournisseurs de services annoncent publiquement qu’ils évitent à leurs clients les problèmes de conformité, mais les petits caractères partagés en privé avec leurs clients sont souvent bien plus modestes.
Ils sont comme des membres de la royauté habillés « à neuf » pour le tapis rouge de l’entrée. Une fois à l’intérieur, lorsqu’on les interroge sur leur tenue, ils répondent « Quoi, ces vieilles guenilles ? ». Le fait d’avoir le beurre et l’argent du beurre complique la tâche de leurs clients qui doivent démontrer qu’ils respectent les règles.
De nombreux clients PCI estiment qu’il est nécessaire d’exiger de meilleures informations que celles actuellement offertes par les TPSP. L’industrie PCI pourrait avoir besoin de tenir les TPSP responsables de la documentation précise des contrôles de sécurité des clients. Jusqu’à ce que la plupart des TPSP deviennent plus précis, les clients qui tentent de démontrer leur propre conformité peuvent être avisés de démontrer et de documenter où leur capacité à avoir un impact sur la sécurité s’arrête, et intuitivement, où il est prouvé que le TPSP soutient ou au moins n’autorise pas l’accès ou les contrôles du client. Ce n’est pas une solution parfaite, mais c’est la seule option dont disposent actuellement de nombreux clients dépendants de PCI.
C’est une caractéristique, pas un bogue
En me référant à l’article « There All Along » de Chris, j’appelle cela le problème de « l’absence d’une source unique de vérité ». Par exemple, je vois certaines exigences en matière de rapports dans un seul modèle de rapport, seulement dans le DSS, seulement dans une FAQ, ou seulement dans un modèle de ROC, mais en quelque sorte pas dans le modèle SAQ D.
Le fait que la vérité se trouve à plusieurs endroits signifie que, dans le meilleur des cas, il faut chercher dans tous les endroits possibles avant de tirer des conclusions. Au pire, cela signifie qu’il faut tirer une conclusion erronée d’une seule source alors qu’il en existe d’autres. Il suffit de dire que je dois tenir une liste des contradictions apparentes dans les diverses sources de l’ICP. Même si beaucoup n’apprécient pas la marge de manœuvre laissée aux QSA dans l’interprétation du champ d’application et des exigences du PCI, ce besoin est si répandu qu’il est considéré comme une caractéristique.
Limites du contrôle des documents
Si la clarté n’est toujours pas au rendez-vous, la seule option pour le client peut être de tester et de documenter ses limites en matière d’impact sur la sécurité des données des titulaires de cartes. Par exemple, si une société de traitement des paiements qui stocke toutes les données des titulaires de cartes ne prétend pas détenir tous les contrôles d’accès logiques aux données stockées, le client peut être amené à dresser la liste de tous les utilisateurs et à tester leur capacité à accéder aux données ou à en gérer l’accès. S’il n’y a pas d’accès aux données stockées, il faut le documenter et espérer que les TPSP deviendront bientôt plus précis et plus utiles dans leurs rapports.
Référence à l’objectif de l’approche personnalisée
Ma méthode la plus simple pour interpréter des contrôles DSS déroutants est de lire l’objectif de l’approche personnalisée. Si l’entité évaluée prend en compte l’objectif de manière exhaustive, il est probable qu’elle puisse démontrer qu’elle est couverte. Inversement, si une entité a respecté les prescriptions PCI dans le cadre de l’approche définie, mais qu’elle n’a pas atteint l’objectif de l’approche personnalisée, il est probable qu’elle ne respecte pas de nombreuses autres exigences. L’objectif de l’approche personnalisée est le moyen le plus simple d’éviter les mauvaises interprétations.
Cher lecteur, est-ce que cela correspond à votre expérience ? Nos consultants peuvent vous aider dans tous ces domaines, n’hésitez donc pas à leur demander de l’aide.