Chaque programme PCI DSS a son dossier d’attestations de conformité (AOC) de ses prestataires, collectées une fois par an, souvent en janvier, souvent dans l’urgence. Le dossier ressemble à une preuve. La plupart du temps, personne n’a lu ce qu’il contient. Quatre cas tirés de nos évaluations.
L’AOC qui couvrait tous les sites sauf le vôtre
Un client avait externalisé une partie de son traitement de cartes à un prestataire de centres d’appels présent sur de nombreux sites. L’AOC du prestataire était à jour, signée par un QSA, et listait les sites du périmètre. Elle en listait beaucoup. Elle ne listait pas celui que notre client utilisait réellement.
C’est l’échec le plus courant que nous voyons, et ce n’est pas de la fraude. Les grands prestataires font évaluer un sous-ensemble de leur parc, souvent les sites qui comptent pour leurs plus grands clients, et l’AOC le dit, dans la section « périmètre » que personne ne lit. Le client classait cette AOC depuis des années comme preuve que son traitement d’appels était couvert.
L’acquéreur dont l’AOC excluait les terminaux qu’il fournissait
Un commerçant encaissait sur des terminaux loués à son acquéreur, qui était aussi le fournisseur des terminaux. L’acquéreur tenait le commerçant pour responsable de la conformité des terminaux, et son AOC le disait explicitement : les exigences sur la protection des équipements contre la manipulation étaient exclues de son périmètre. Son manuel d’installation, pendant ce temps, imprimait le mot de passe administrateur par défaut des terminaux et celui du téléchargement de logiciels.
On ne peut pas hériter d’un contrôle d’un prestataire dont l’AOC ne le couvre pas. Nous avons envoyé au prestataire une lettre formelle de questions, une exigence à la fois, demandant des preuves plutôt que des assurances. La conformité du commerçant s’est alors déplacée là où elle se trouvait vraiment : un inventaire des terminaux, des inspections quotidiennes, la formation du personnel et une voie d’escalade, et une matrice de responsabilités convenue par écrit avec l’acquéreur.
On ne peut pas hériter d’un contrôle d’un prestataire dont l’AOC ne le couvre pas.
Les prestataires qui ont envoyé un SAQ A de commerçant
Un opérateur de transport public reprenant un réseau a hérité de huit prestataires de paiement et d’une demande de validation PCI de son autorité organisatrice. Il a collecté les AOC des prestataires comme preuve. Deux des prestataires clés avaient envoyé l’AOC de leur propre SAQ A de commerçant, le plus court des questionnaires d’auto-évaluation. Un SAQ A de commerçant décrit comment une société encaisse ses propres paiements par une page externalisée. Il ne dit strictement rien du service que cette société fournit à qui que ce soit d’autre.
Nous ne pouvions pas valider un SAQ A pour l’opérateur au motif que le traitement était externalisé et que des documents avaient été collectés. Le travail qui aurait dû venir en premier était clair : rattacher chaque canal à son compte commerçant, vérifier ce que chaque document hérité couvrait réellement, et choisir l’approche de validation canal par canal.
La mission avait commencé par « vous êtes QSA, nous avons besoin que vous signiez ce SAQ A avec nous ». Le SAQ A ne s’appliquait pas à l’essentiel du parc, donc nous ne l’avons pas fait. Nous n’avons jamais vu la fin de l’histoire. Notre hypothèse est que l’opérateur a signé lui-même le SAQ A, que l’autorité a accepté un document auto-signé qui ne décrivait pas la situation, et que le projet s’est clos ainsi. Un QSA ne peut pas tordre la règle. L’entité qui demande une attestation et celle qui y répond le peuvent toutes deux, et le font parfois. Notre position a été d’être clairs sur les règles et sur notre décision, même là où cela passe pour un message négatif. Nous n’écrivons pas les règles, et nous ne les tordons pas non plus.
L’AOC qui ne peut pas exister
Le client d’un fournisseur d’infrastructure de paiement a demandé « une AOC pour le domaine du fournisseur ». Le fournisseur attesterait l’infrastructure de paiement, le client garderait le droit d’en modifier la configuration, et informerait le fournisseur des changements une fois par trimestre. Sept domaines de responsabilité étaient sur la table. Cinq n’avaient pas de responsable convenu.
Une AOC est la déclaration d’une entité juridique sur elle-même. Il n’existe pas d’AOC pour un ensemble d’équipements, pas plus qu’il n’existe de passeport pour une salle serveur. Et une notification trimestrielle n’est pas une gestion des changements. La vraie question était une bifurcation, technique et non commerciale. Soit le client garde la maîtrise des changements et est l’entité évaluée, avec le fournisseur listé comme tiers dans une matrice de responsabilités signée. Soit le fournisseur atteste, et chaque changement passe par lui. Les deux à la fois est impossible. La meilleure preuve était déjà sur la table : la nomination des gardiens de clés était bloquée depuis deux mois parce que personne ne pouvait dire quelle ligne hiérarchique les autorise.
Ce que l’on fait de travers
On collecte une AOC une fois, à la signature du contrat, et on la classe. L’AOC est datée, délimitée et signée pour une période. L’année suivante, elle décrit l’année passée.
On ne lit pas le périmètre. La section « périmètre » dit quels services, quels sites et quelles exigences l’attestation couvre. Si le service que vous achetez n’y figure pas, vous avez un joli document sur autre chose.
On n’a pas de matrice de responsabilités. Le standard en demande une exactement pour cette raison : pour que chaque exigence ait un nom en face, le vôtre ou le leur. Sans elle, le premier évaluateur qui demande « qui fait ça ? » voit deux sociétés se renvoyer la question.
On prend une AOC pour un contrôle. L’attestation d’un prestataire vous dit que le prestataire affirme que ses contrôles ont fonctionné. Elle n’inspecte pas vos terminaux, ne corrige pas vos serveurs et ne forme pas votre personnel. Les exigences qui restent les vôtres sont généralement celles qui causent les compromissions.