PCI DSS v4.0.1 (exigences 6 et 11)
Attestkeep rattache ce que l'admission control et le scan d'images de votre cluster ont enregistré sur une période à 13 exigences (source : PCI Security Standards Council, Payment Card Industry Data Security Standard, version 4.0.1, juin 2024). 8 sont évaluées sur ces enregistrements ; 5 sont marquées hors périmètre, chacune avec la raison.
8 exigences à portée de cluster.
Références et titres tels que le rapport les imprime, c'est-à-dire en anglais. Ouvrez une exigence pour lire ce qu'elle demande, reformulé au plus près du texte de l'instrument.
PCI DSS v4.0.1
PCI Security Standards Council, Payment Card Industry Data Security Standard, version 4.0.1, juin 2024
Exigences 6.3 et 6.5 (gestion des vulnérabilités et contrôle des changements), exigence 10.2 (journaux d'audit) et exigence 11.3 (scans de vulnérabilités internes)
| Référence | Exigence | Sections du rapport |
|---|---|---|
| Requirement 6.3.1 | Security vulnerabilities are identified and risk-rankedLes nouvelles vulnérabilités de sécurité sont identifiées à partir de sources d'information reconnues par la profession, y compris les alertes des CERT nationaux et internationaux, et reçoivent un classement de risque qui identifie au moins toutes les vulnérabilités jugées à haut risque ou critiques pour l'environnement ; les vulnérabilités des logiciels développés sur mesure et des logiciels tiers, comme les systèmes d'exploitation et les bases de données, sont couvertes. | CoverageClusterAdmission decisionsOutcomesDeployment contextControl statement |
| Requirement 6.3.2 | Inventory of bespoke, custom and third-party software componentsUn inventaire des logiciels développés sur mesure et des composants logiciels tiers qu'ils intègrent est tenu à jour pour faciliter la gestion des vulnérabilités et des correctifs. | Supply chainCoverage |
| Requirement 6.3.3 | System components are protected from known vulnerabilities by patchingTous les composants du système sont protégés des vulnérabilités connues par l'installation des correctifs de sécurité applicables : les correctifs des vulnérabilités critiques, identifiées selon le classement de l'exigence 6.3.1, dans le mois qui suit leur publication, et tous les autres correctifs applicables dans un délai approprié fixé par l'évaluation de la criticité du risque par l'entité. | Control statementCoverageAdmission decisionsOutcomes |
| Requirement 6.5.1 | Changes to system components follow change control proceduresLes changements apportés à tous les composants du système en production suivent des procédures établies : raison et description du changement, impact de sécurité documenté, approbation documentée par des personnes habilitées, tests vérifiant que le changement ne nuit pas à la sécurité du système, tests des mises à jour de logiciels sur mesure au regard de l'exigence 6.2.4 avant leur mise en production, et procédures de gestion des échecs et de retour à un état sûr. | Admission decisionsEvidence chain |
| Requirement 10.2.2 | What each audit log entry recordsLes journaux d'audit enregistrent, pour chaque événement auditable, l'identification de l'utilisateur, le type d'événement, la date et l'heure, l'indication de succès ou d'échec, l'origine de l'événement et l'identité ou le nom des données, composants système, ressources ou services concernés. | Evidence chain |
| Requirement 11.3.1 | Internal vulnerability scans at least once every three monthsDes scans de vulnérabilités internes sont effectués au moins une fois tous les trois mois, les vulnérabilités à haut risque et critiques sont résolues, de nouveaux scans confirment leur résolution, l'outil de scan est tenu à jour des informations sur les vulnérabilités, et les scans sont menés par un personnel qualifié, avec une indépendance organisationnelle du testeur. | CoverageAdmission decisionsOutcomesControl statementIssues |
| Requirement 11.3.1.1 | Vulnerabilities not ranked high-risk or criticalToutes les autres vulnérabilités applicables sont traitées selon le risque défini dans l'analyse de risque ciblée de l'entité, avec de nouveaux scans si nécessaire. | Triage decisionsCoverageDeployment context |
| Requirement 11.3.1.2 | Internal scans are performed via authenticated scanningLes scans de vulnérabilités internes sont authentifiés, avec des privilèges suffisants pour les systèmes qui acceptent des identifiants ; ceux qui ne le peuvent pas sont documentés, et tout compte utilisé pour le scan authentifié qui permet aussi une connexion interactive est géré selon l'exigence 8.2.2. | Coverage |
5 exigences hors périmètre, et pourquoi
| Référence | Exigence et raison |
|---|---|
| Requirement 6.4.2 | Automated protection for public-facing web applications Ce contrôle décide quelle image peut tourner ; il ne voit rien du trafic auquel l'application répond ensuite, et c'est là qu'arrive une attaque web. |
| Requirement 6.4.3 | Payment page scripts are authorised, integrity-assured and inventoried Les scripts qu'une page de paiement sert au navigateur sont du contenu que l'application génère en fonctionnement, en aval de l'image que ce contrôle admet, et invisible pour lui. |
| Requirement 10.2.1 | Audit logs are enabled and active La journalisation s'active composant par composant dans l'environnement de l'entité ; ce document atteste le journal que ce contrôle tient de ses propres décisions, rapporté en 10.2.2 ci-dessous, et ne peut rien dire du reste. |
| Requirement 11.3.2 | External vulnerability scans by an Approved Scanning Vendor Un ASV scanne la surface d'attaque externe de l'entité depuis l'extérieur et rend compte selon l'ASV Program Guide ; rien de cette mission n'est observable depuis l'intérieur d'un cluster. |
| Requirement 12.3.1 | Targeted risk analysis for a frequency the entity sets L'analyse qui fixe la fréquence de 11.3.1.1 est un document que l'entité rédige, approuve et réexamine ; ce contrôle fonctionne à la fréquence qui en résulte et ne peut pas la remplacer. |
Preuves tirées des journaux que tient déjà le cluster.
Rien n'est rempli à la main. La réponse à chaque exigence porte un statut (satisfaite, partielle, écart ou hors périmètre), une note avec les chiffres de la période et les sections du rapport d'où viennent ces chiffres.
Ce sur quoi s'appuie le mapping
Chaque exigence évaluée reçoit sa réponse d'une ou plusieurs de ces affirmations sur les enregistrements de la période. La même affirmation répond à la même question dans tous les frameworks : deux rapports sur une même période ne peuvent pas diverger.
- Chaque image de l'inventaire a un enregistrement de scan4 exigences
- Les images portant des vulnérabilités graves sont refusées3 exigences
- Chaque décision et chaque action d'administration est enregistrée2 exigences
- Les seuils de vulnérabilité sont plus stricts là où le workload est exposé ou privilégié2 exigences
- L'admission refuse les workloads non conformes1 exigence
- Chaque changement d'image est enregistré avec la policy qui le régissait1 exigence
- Les risques acceptés sont nommés, justifiés et expirent1 exigence
- Les vulnérabilités trouvées sont croisées avec un catalogue national de vulnérabilités exploitées1 exigence
- Les vulnérabilités critiques ont un délai de correction d'un mois au plus1 exigence
- Un délai de correction est déclaré pour chaque sévérité1 exigence
- Un SBOM est conservé pour les images en service1 exigence
- Les images sont scannées par un pull authentifié avec les identifiants du workload1 exigence
Ce que contient le rapport.
Chaque paquet contient les mêmes sections, quel que soit le framework. Les sections signalées sont celles que citent les réponses pour PCI DSS, avec le nombre d'exigences qui renvoient à chacune.
- Organisation
- Framework mapping
- Cluster1
- Control statement3
- Coverage6
- Vulnerability findings
- Outcomes3
- Admission decisions4
- Supply chain1
- Triage decisions1
- Break-glass events
- Availability
- Evidence chain2
- Deployment context2
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
Le paragraphe de périmètre, tel que le rapport l'imprime (en anglais).
This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto PCI DSS v4.0.1. It is not a Report on Compliance and not an Attestation of Compliance: those are issued by a Qualified Security Assessor or a qualified internal resource against the entity's whole cardholder data environment, and only the entity defines what is in that environment. Nothing here establishes that this cluster is in scope for PCI DSS, or that it is out of it. What the period's records support is the vulnerability management clauses of Requirement 6 and the internal scanning clauses of Requirement 11 for the images this cluster admitted, together with the audit log clauses of 10.2 for the decisions it took. The document records the version of the CISA Known Exploited Vulnerabilities catalogue the period's decisions were taken against, which is one of the industry-recognised sources Requirement 6.3.1 asks for; the mapping below reads the scan and admission records rather than that catalogue directly. Account data at rest and in transit, the web application and payment page clauses of 6.4, the Approved Scanning Vendor scans of 11.3.2 and the organisational programme of Requirement 12 are outside what a cluster observes and are marked as such.
Sur PCI DSS
Est-ce une certification selon PCI DSS ?
Non. Le paquet est une preuve produite à partir des enregistrements de votre cluster. Ce n'est pas une certification, et aucun auditeur n'est tenu de l'accepter. Le paragraphe de périmètre de cette page est celui que porte le rapport lui-même.
Pourquoi 5 exigences sont-elles hors périmètre ?
Elles portent sur des choses que les enregistrements d'admission et de scan d'un cluster ne peuvent pas montrer. Elles figurent avec la raison au lieu d'être omises, pour que le lecteur du rapport voie que l'exclusion est voulue.
Quel plan inclut PCI DSS ?
Tous les plans peuvent produire un rapport selon ce framework. Community et Team incluent un framework au choix, Business trois, Enterprise tous. Les prix sont sur la page des tarifs.
Comment un auditeur vérifie-t-il le paquet ?
Dans un navigateur, sur attestkeep.com/verify.html, où rien n'est envoyé, ou avec le court script du site de documentation. Aucun des deux n'a besoin de nous. La page Pour les auditeurs donne le détail.
Installez-le vous-même.
Créez un compte, confirmez votre e-mail avec le code envoyé, prenez la clé Community gratuite sur la page Licences et installez avec Helm.
Créer un compte