Sicherheit · International (PCI SSC)

PCI DSS v4.0.1 (Anforderungen 6 und 11)

Was Admission Control und Image-Scan Ihres Clusters in einem Zeitraum erfasst haben, ordnet Attestkeep 13 Anforderungen zu (Quelle: PCI Security Standards Council, Payment Card Industry Data Security Standard, Version 4.0.1, Juni 2024). 8 davon werden aus diesen Einträgen bewertet; 5 sind als außerhalb des Umfangs markiert, jede mit Begründung.

Konto anlegen Wie ein Paket entsteht

Was das Framework verlangt

8 Anforderungen aus Clustersicht.

Fundstellen und Titel so, wie der Bericht sie druckt, also auf Englisch. Öffnen Sie eine Anforderung, um zu lesen, was sie verlangt – nah am Wortlaut des Regelwerks wiedergegeben.

PCI DSS v4.0.1

PCI Security Standards Council, Payment Card Industry Data Security Standard, Version 4.0.1, Juni 2024

Anforderung 6.3 und 6.5 (Schwachstellenmanagement und Änderungskontrolle), Anforderung 10.2 (Audit-Logs) und Anforderung 11.3 (interne Schwachstellenscans)

Fundstelle	Anforderung	Berichtsabschnitte
Requirement 6.3.1	Security vulnerabilities are identified and risk-ranked Neue Sicherheitsschwachstellen werden anhand branchenweit anerkannter Quellen für Schwachstelleninformationen erkannt, einschließlich Warnungen nationaler und internationaler CERTs, und erhalten eine Risikoeinstufung, die mindestens alle für die Umgebung als hoch oder kritisch geltenden Schwachstellen kennzeichnet; erfasst werden Schwachstellen in individuell entwickelter Software und in Software Dritter wie Betriebssystemen und Datenbanken.	CoverageClusterAdmission decisionsOutcomesDeployment contextControl statement
Requirement 6.3.2	Inventory of bespoke, custom and third-party software components Ein Inventar der individuell entwickelten Software und der darin enthaltenen Softwarekomponenten Dritter wird gepflegt, um Schwachstellen- und Patch-Management zu erleichtern.	Supply chainCoverage
Requirement 6.3.3	System components are protected from known vulnerabilities by patching Alle Systemkomponenten werden durch Installation der zutreffenden Sicherheitspatches vor bekannten Schwachstellen geschützt: Patches für kritische Schwachstellen, eingestuft nach dem Verfahren aus Anforderung 6.3.1, innerhalb eines Monats nach Veröffentlichung, alle übrigen zutreffenden Sicherheitspatches innerhalb eines angemessenen Zeitraums, den die Organisation nach ihrer Bewertung der Kritikalität des Risikos festlegt.	Control statementCoverageAdmission decisionsOutcomes
Requirement 6.5.1	Changes to system components follow change control procedures Änderungen an allen Systemkomponenten der Produktionsumgebung erfolgen nach festgelegten Verfahren: Grund und Beschreibung der Änderung, dokumentierte Sicherheitsauswirkung, dokumentierte Genehmigung durch befugte Personen, Tests, dass die Änderung die Systemsicherheit nicht beeinträchtigt, Prüfung individuell entwickelter Software-Updates auf Einhaltung von Anforderung 6.2.4 vor der Freigabe in die Produktion sowie Verfahren für den Umgang mit Fehlschlägen und die Rückkehr in einen sicheren Zustand.	Admission decisionsEvidence chain
Requirement 10.2.2	What each audit log entry records Audit-Logs halten für jedes auditierbare Ereignis fest: Benutzerkennung, Ereignistyp, Datum und Uhrzeit, Erfolg oder Fehlschlag, Ursprung des Ereignisses und Identität oder Name der betroffenen Daten, Systemkomponente, Ressource oder des Dienstes.	Evidence chain
Requirement 11.3.1	Internal vulnerability scans at least once every three months Interne Schwachstellenscans erfolgen mindestens einmal alle drei Monate, Schwachstellen mit hohem Risiko und kritische Schwachstellen werden behoben, erneute Scans bestätigen die Behebung, das Scan-Werkzeug wird mit aktuellen Schwachstelleninformationen versorgt, und die Scans führt qualifiziertes, organisatorisch unabhängiges Personal durch.	CoverageAdmission decisionsOutcomesControl statementIssues
Requirement 11.3.1.1	Vulnerabilities not ranked high-risk or critical Alle übrigen zutreffenden Schwachstellen werden entsprechend dem Risiko behandelt, das in der gezielten Risikoanalyse der Organisation festgelegt ist, mit erneuten Scans nach Bedarf.	Triage decisionsCoverageDeployment context
Requirement 11.3.1.2	Internal scans are performed via authenticated scanning Interne Schwachstellenscans erfolgen authentifiziert, mit ausreichenden Berechtigungen für Systeme, die Zugangsdaten annehmen; Systeme, die das nicht können, werden dokumentiert, und jedes für authentifizierte Scans genutzte Konto, mit dem man sich auch interaktiv anmelden kann, wird nach Anforderung 8.2.2 verwaltet.	Coverage

5 Anforderungen außerhalb des Umfangs, und warum

Fundstelle	Anforderung und Grund
Requirement 6.4.2	Automated protection for public-facing web applications Diese Kontrolle entscheidet, welches Image laufen darf; vom Datenverkehr, den die Anwendung danach beantwortet, sieht sie nichts, und genau dort kommt ein webbasierter Angriff an.
Requirement 6.4.3	Payment page scripts are authorised, integrity-assured and inventoried Die Skripte, die eine Zahlungsseite an einen Browser ausliefert, erzeugt die Anwendung erst im laufenden Betrieb; sie liegen unterhalb des Images, das diese Kontrolle zulässt, und sind für sie unsichtbar.
Requirement 10.2.1	Audit logs are enabled and active Die Protokollierung wird Komponente für Komponente in der Umgebung der Organisation aktiviert; dieses Dokument belegt das Log, das diese Kontrolle über ihre eigenen Entscheidungen führt und über das 10.2.2 unten berichtet, und kann über den Rest nichts sagen.
Requirement 11.3.2	External vulnerability scans by an Approved Scanning Vendor Ein ASV scannt die externe Angriffsfläche der Organisation von außen und berichtet nach dem ASV Program Guide; nichts an diesem Auftrag ist aus einem Cluster heraus beobachtbar.
Requirement 12.3.1	Targeted risk analysis for a frequency the entity sets Die Analyse, die die Häufigkeit für 11.3.1.1 festlegt, ist ein Dokument, das die Organisation schreibt, genehmigt und überprüft; diese Kontrolle arbeitet in der Häufigkeit, die dabei herauskommt, und kann die Analyse nicht ersetzen.

Was Attestkeep erzeugt

Nachweise aus Einträgen, die der Cluster ohnehin führt.

Nichts wird von Hand ausgefüllt. Jede Antwort zu einer Anforderung trägt einen Status (erfüllt, teilweise, Lücke oder außerhalb des Umfangs), eine Notiz mit den Zahlen des Zeitraums und die Berichtsabschnitte, aus denen diese Zahlen stammen.

Worauf sich das Mapping stützt

Jede bewertete Anforderung wird durch eine oder mehrere dieser Aussagen über die Einträge des Zeitraums beantwortet. Dieselbe Aussage beantwortet dieselbe Frage in jedem Framework; zwei Berichte über denselben Zeitraum können sich daher nicht widersprechen.

Jedes Image im Bestand hat einen Scan-Eintrag4 Anforderungen
Images mit schweren Befunden werden abgelehnt3 Anforderungen
Jede Entscheidung und jede administrative Aktion wird festgehalten2 Anforderungen
Schwellenwerte für Schwachstellen sind strenger, wo der Workload exponiert oder privilegiert ist2 Anforderungen
Admission lehnt nicht konforme Workloads ab1 Anforderung
Jede Image-Änderung wird zusammen mit der Policy festgehalten, die für sie galt1 Anforderung
Akzeptierte Risiken sind benannt, begründet und laufen ab1 Anforderung
Befunde werden mit einem nationalen Katalog ausgenutzter Schwachstellen abgeglichen1 Anforderung
Kritische Befunde haben ein Behebungsfenster von höchstens einem Monat1 Anforderung
Für jeden Schweregrad ist ein Behebungsfenster festgelegt1 Anforderung
Für die laufenden Images liegt ein SBOM vor1 Anforderung
Images werden als authentifizierter Pull mit den eigenen Zugangsdaten des Workloads gescannt1 Anforderung

Das Paket

Was der Bericht enthält.

Jedes Paket enthält dieselben Abschnitte, unabhängig vom Framework. Markiert sind die, auf die sich die Antworten zu PCI DSS stützen, jeweils mit der Zahl der Anforderungen, die auf sie verweisen.

Mehr zum Paket

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)

Umfang

Geltungsbereich, wörtlich aus dem Bericht (Englisch).

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.

Fragen

Fragen zu PCI DSS

Ist das eine Zertifizierung nach PCI DSS?

Nein. Das Paket ist ein Nachweis aus den clustereigenen Einträgen. Es ist keine Zertifizierung, und kein Auditor muss es anerkennen. Der Absatz zum Geltungsbereich auf dieser Seite ist derselbe, den auch der Bericht enthält.

Warum liegen 5 Anforderungen außerhalb des Umfangs?

Sie fragen nach Dingen, die die Admission- und Scan-Einträge eines einzelnen Clusters nicht zeigen können. Sie werden mit Begründung aufgeführt statt weggelassen, damit jeder Leser des Berichts sieht, dass der Ausschluss bewusst ist.

Welcher Plan enthält PCI DSS?

Jeder Plan kann danach berichten. Community und Team enthalten 1 Framework Ihrer Wahl, Business 3, Enterprise alle. Die Preise stehen auf der Preisseite.

Wie prüft ein Auditor das Paket?

Im Browser unter attestkeep.com/verify.html, wo nichts hochgeladen wird, oder mit dem kurzen Skript auf der Dokumentationsseite. Beides kommt ohne uns aus. Einzelheiten stehen unter Für Auditoren.

Selbst installieren.

Konto anlegen, die E-Mail mit dem zugesandten Code bestätigen, den kostenlosen Community-Schlüssel auf der Seite Licences holen und mit Helm installieren.

Konto anlegen