Kliper mène une évaluation PCI P2PE v3.2 dans le même éditeur d’exigences qu’un ROC PCI DSS. Chaque évaluation porte sur un seul P2PE Report on Validation (P-ROV) : vous renseignez ses détails du rapport, une constatation et les réponses de l’évaluateur pour chaque exigence, et les réponses que demande son Attestation of Validation (P-AOV), puis vous exportez les deux.
Déroulement d’une évaluation P2PE
Créer l'évaluation
Choisissez PCI P2PE 3.2 et le P-ROV sur lequel elle porte.
Renseigner les détails du rapport
Contacts et dates, le produit et ses fournisseurs de composants, le périmètre, les diagrammes, les sites, les documents, les personnes interrogées et les échantillons.
Évaluer chaque exigence
Pour chaque exigence, choisissez une constatation et rédigez la réponse de l’évaluateur à chaque instruction de rapport de chaque procédure de test.
Expliquer les exigences N/A et compléter le P-AOV
Listez chaque exigence N/A en 4.2 avec sa raison, puis répondez à ce que le P-AOV demande au-delà du rapport.
Exporter
Téléchargez le P-ROV et le P-AOV en Word ou en PDF, après les contrôles d’export.
Créer une évaluation P2PE
Dans Création rapide, choisissez PCI P2PE 3.2 : un champ Rapport de validation (P-ROV) apparaît, où vous choisissez le P-ROV. Dans l’assistant complet, sélectionnez PCI P2PE et la version 3.2 à l’étape Référentiel, puis choisissez le Rapport de validation (P-ROV) à l’étape Périmètre et visibilité. Plus d’options reporte les deux de Création rapide vers l’assistant complet, et inversement. Un fournisseur de solution qui a besoin de plusieurs P-ROV (celui de la Solution et un EMS, par exemple) crée une évaluation pour chacun dans le même engagement. Le P-ROV ne peut plus être changé après la création. Voir Créer une évaluation pour la suite du parcours.
| Report on Validation | Couvre | Exigences | Procédures de test |
|---|---|---|---|
| P2PE Solution | Domaine 3 | 19 | 36 |
| Encryption Management Services | Domaines 1 et 5 | 175 | 322 |
| Decryption Management Services | Domaines 4 et 5 | 236 | 467 |
| Key Management Services | Domaine 5 | 281 | 507 |
| Merchant-Managed Solution | Domaine 3 et annexe A | 34 | 65 |
| P2PE Application | Domaine 2 | 62 | 113 |
Chaque P-ROV garde la formulation de son modèle : l’EMS et le DMS formulent différemment certaines exigences du domaine 5.
Ce que contient l’évaluation
Les exigences sont affichées avec les numéros qu’imprime le P-ROV : 1A-1.1, 6-1.1, 5I-1.1, MM-A-2.1. Chaque section a sa page sous son domaine (1A sous le domaine 1), et le domaine 5 est paginé par Control Objective, ses exigences regroupées en Requirement 6, Requirement 7. Dans les P-ROV EMS et KMS, chaque procédure de test indique les types de composant auxquels elle s’applique.
Les détails du rapport
La section 1 est la même dans tous les P-ROV ; les sections 2 et 3 sont propres à chaque modèle.
| Élément | Ce que vous renseignez |
|---|---|
| 1.1 à 1.4 | L’entité évaluée, la société P2PE Assessor et l’évaluateur principal, l’affirmation du contrôle qualité interne et le relecteur QA, les éventuels évaluateurs supplémentaires, les dates, les services déclarés, l’affirmation de la v3.2 |
| 2.1 | Le produit : son nom, s’il est listé et sa référence ; pour un P-ROV de composant, s’il est soumis avec l’évaluation d’une Solution ou comme composant, et son type ; pour une application, le type d’évaluation auquel elle se rattache |
| 2.2 et suivants | Les fournisseurs de composants validés, les tiers, les applications, les terminaux POI, les SCD, les implémentations de chiffrement supplémentaires et le résumé de conformité, comme le demande le modèle |
| Section 3 | Le périmètre, les diagrammes, les sites, les documents, les personnes interrogées, les terminaux échantillonnés, la matrice des clés et, là où le modèle le demande, les transactions de test et les jeux d’échantillons |
| 4.1 | Le Summary of Findings, chaque ligne du modèle lue à partir des constatations |
| 4.2 | Chaque exigence jugée N/A et pourquoi. Add the requirements from the findings les liste |
Une question posée seulement selon une autre réponse (une référence de listing après Yes, le type d’un composant une fois que 2.1 dit qu’il est évalué comme tel) apparaît, et compte dans la progression, seulement à ce moment. Sur un P-ROV Decryption Management Services, 4D demande si l’environnement est un environnement de déchiffrement hybride et 4E-1 si le fournisseur est un P2PE Component Provider : sinon, le modèle laisse 4D et 5H, ou 4E-1.1 à 4E-1.2.b, vides ou N/A.
Enregistrer une constatation
Pour chaque exigence, choisissez une constatation :
| Constatation | Quand |
|---|---|
| In Place | L’exigence est satisfaite |
| N/A | L’exigence, après tests et revue, ne s’applique pas au produit |
| Not in Place | L’exigence n’est pas satisfaite |
P2PE n’a pas de résultat Not Tested et n’admet aucun contrôle compensatoire. Rédigez ensuite la réponse de l’évaluateur à chaque instruction de rapport : ce qui a été examiné, observé ou recueilli en entretien, et ce que cela a montré. Une constatation N/A se rapporte de la même façon, en disant comment il a été déterminé qu’elle ne s’applique pas, et figure en 4.2.
Une ligne du Summary of Findings indique Not in Place quand une exigence qu’elle couvre l’est, N/A quand toutes le sont, et In Place sinon : un mélange de In Place et de N/A.
Les réponses du P-AOV
Les pages de l’Attestation of Validation ne demandent que ce que le rapport ne donne pas. Son formulaire suit le P-ROV :
| P-ROV | P-AOV |
|---|---|
| Solution, composant évalué comme tel, application listée séparément | Le P2PE Product P-AOV (v3.1) |
| Merchant-Managed Solution | L’AOV P2PE Merchant-Managed Solution (v3.0) |
| Application validée dans le cadre d’une Merchant-Managed Solution | Son propre AOV (v3.0) |
| Composant soumis avec l’évaluation d’une Solution, application évaluée uniquement pour une Solution | Aucun qui lui soit propre : celui de la Solution le couvre |
| Page | Ce que vous renseignez |
|---|---|
| Type de soumission ou de validation | Administrative Change, Delta Change, Annual Revalidation ou Full Assessment, selon ce que propose le formulaire |
| Fournisseur et évaluateur | Les parties et leurs adresses. Fill from 1.1 copie les contacts du rapport |
| Parties 3b à 3e (Merchant-Managed Solution) | Les terminaux POI, les applications, les HSM et les fournisseurs de composants listés |
Le produit, son type et son listing viennent de 2.1 ; les terminaux d’une application MMS, de son 2.5. Les attestations, leurs dates et les signatures se font sur le document exporté.
Exporter le P-ROV et le P-AOV
Cliquez sur Export dans l’en-tête de l’évaluation, ou dans le menu Actions de la barre supérieure. Choisissez le Report on Validation, l’Attestation of Validation ou les deux, en PDF ou en Word. La carte du P-AOV est indisponible quand 2.1 dit que le P-ROV n’en a pas qui lui soit propre. Un PDF inachevé peut porter le filigrane DRAFT.
Avant de produire le fichier, Kliper lance les contrôles d’export. Les bloquants sont ce qu’exige le P-ROV ; les avertissements méritent un second regard. Export anyway produit le fichier quand même.
| Contrôle | Gravité |
|---|---|
| Une exigence avec une constatation dont toutes les instructions de rapport n’ont pas de réponse (« N/A » ou « see … » seul compte comme aucune réponse, sauf s’il cite Doc-1 ou Int-1, et jamais pour un N/A) | Bloquant |
| Une constatation Not Tested ou un contrôle compensatoire enregistré auparavant, que le P-ROV ne prévoit pas | Bloquant |
| Une exigence N/A non expliquée en 4.2 (une ligne peut nommer une exigence, son groupe, une section ou Requirement 6) | Bloquant |
| 4.2 liste une exigence que les constatations ne donnent pas N/A | Avertissement |
| 4.2 nomme un numéro sous lequel le P-ROV n’a aucune exigence (une coquille, celui d’un autre P-ROV) | Avertissement |
| Une exigence Not in Place : le produit n’est pas validé | Avertissement |
| Une exigence DMS rapportée alors que 4D ou 4E-1 l’écarte | Avertissement |
| Un élément de diagramme sans diagramme | Avertissement |
| Une réponse qui répète sa procédure de test ou son instruction, est copiée d’une autre exigence, ou décrit un travail futur sous In Place | Avertissement |
Cortex sur une évaluation P2PE
Cortex lit l’évaluation P2PE comme son P-ROV : le texte d’une exigence et ses procédures de test avec leurs instructions de rapport et les types de composant auxquels chacune s’applique, vos constatations et réponses, le Summary of Findings, les détails du rapport, le P-AOV tel que rempli, et les contrôles d’export. Il nomme les exigences comme les imprime le P-ROV. Cortex n’enregistre pas les réponses P2PE : demandez-lui de rédiger une réponse et il écrit le brouillon dans sa réponse, pour que vous le relisiez et le colliez. La constatation vous appartient toujours.