PCI DSS: der Scan ist nur der Anfang

Für wen gilt PCI DSS, und wer prüft?

Der Payment Card Industry Data Security Standard gilt für jede Stelle, die Kontodaten von Zahlungskarten speichert, verarbeitet oder überträgt, und für alle, die die Sicherheit dieser Umgebung beeinflussen können. Das sind Händler und Zahlungsdienstleister ebenso wie Rechenzentren und Softwareanbieter, soweit diese Kontodaten verarbeiten oder Zugriff auf die Umgebung ihrer Kunden haben. PCI DSS ist kein Gesetz, sondern wird über die Verträge mit der akquirierenden Bank und den Kartenmarken verbindlich. Bei Verstößen drohen Vertragsstrafen, höhere Gebühren oder der Verlust der Kartenakzeptanz.

Wie die Einhaltung nachgewiesen wird, hängt vom Transaktionsvolumen und der Rolle ab. Die größten Händler und Dienstleister lassen sich jährlich prüfen, in der Regel von einem Qualified Security Assessor (QSA), bei manchen Kartenmarken auch von internen Prüfern. Ergebnis ist ein Report on Compliance (ROC). Kleinere Händler füllen meist einen Selbstbewertungsfragebogen (SAQ) aus. Die Schwellen legen die Kartenmarken fest, maßgeblich ist, was der Acquirer verlangt. In beiden Fällen wird das Ergebnis mit einer Attestation of Compliance (AOC) bestätigt.

PCI DSS 4.0.1: die aktuelle Version

Version 4.0 erschien im März 2022 und löste zum 31. März 2024 die Version 3.2.1 ab. Im Juni 2024 folgte mit 4.0.1 eine begrenzte Überarbeitung mit Klarstellungen, seit dem Jahreswechsel 2024/25 ist sie die einzig gültige Fassung. Die in 4.0 als zukünftig gekennzeichneten Anforderungen sind seit dem 31. März 2025 verpflichtend.

Neu in Version 4 ist neben dem festgelegten Ansatz ein angepasster Ansatz: Eine Organisation darf ein Ziel mit eigenen Maßnahmen erreichen, wenn sie das mit einer gezielten Risikoanalyse nach 12.3.2 begründet und ein Assessor (QSA oder ISA) es im ROC bestätigt. Mit einem SAQ ist der angepasste Ansatz nicht möglich. Gezielte Risikoanalysen nach Anforderung 12.3.1 braucht es außerdem überall dort, wo der Standard die Häufigkeit einer Tätigkeit der Organisation überlässt.

Die 12 Anforderungen in sechs Zielbereichen

Der Standard ist in sechs Ziele gegliedert, die zwölf Hauptanforderungen mit mehreren hundert Einzelanforderungen enthalten:

• Sichere Netze und Systeme: 1 Netzwerksicherheitskontrollen einrichten und pflegen, 2 sichere Konfigurationen für alle Systemkomponenten anwenden.
• Schutz der Kontodaten: 3 gespeicherte Kontodaten schützen, 4 Karteninhaberdaten bei der Übertragung über offene, öffentliche Netze mit starker Kryptografie schützen.
• Schwachstellenmanagement: 5 Systeme und Netze vor Schadsoftware schützen, 6 sichere Systeme und Software entwickeln und pflegen.
• Starke Zugriffskontrolle: 7 Zugriff nach geschäftlichem Bedarf beschränken, 8 Nutzer identifizieren und authentifizieren, 9 physischen Zugang beschränken.
• Überwachen und testen: 10 alle Zugriffe protokollieren und überwachen, 11 die Sicherheit von Systemen und Netzen regelmäßig testen.
• Informationssicherheitsleitlinie: 12 Informationssicherheit mit organisatorischen Richtlinien und Programmen unterstützen.

Die Karteninhaber-Datenumgebung (CDE) und der Geltungsbereich

Zur Karteninhaber-Datenumgebung gehören alle Systemkomponenten, die Karteninhaberdaten oder sensible Authentifizierungsdaten speichern, verarbeiten oder übertragen. Im Geltungsbereich liegen aber auch Systeme, die mit der CDE verbunden sind oder ihre Sicherheit beeinflussen können, etwa Verzeichnisdienste, Protokollserver oder Sprungrechner. Sensible Authentifizierungsdaten wie die Kartenprüfnummer dürfen nach der Autorisierung nicht gespeichert werden.

Der Geltungsbereich ist mindestens jährlich und nach wesentlichen Änderungen zu dokumentieren und zu bestätigen, für Dienstleister halbjährlich. Dazu gehören Netz- und Datenflussdiagramme und ein Inventar der Systemkomponenten. Ihn klein zu halten, spart Aufwand: durch Netzwerksegmentierung, Tokenisierung, Punkt-zu-Punkt-Verschlüsselung oder eine Bezahlseite, die vollständig beim Zahlungsdienstleister liegt. Segmentierung wirkt nur, wenn sie getestet ist, jährlich und für Dienstleister halbjährlich.

Das PCI-DSS-Modul führt die CDE mit ihren Komponenten. Die Segmentierung steht und fällt mit den Firewall-Regeln, die das Firewall-Management über mehrere Hersteller hinweg dokumentiert.

Der ASV-Scan nach Anforderung 11.3.2

Anforderung 11.3.2 verlangt mindestens vierteljährlich einen externen Schwachstellenscan durch einen Approved Scanning Vendor (ASV), einen vom PCI Security Standards Council zugelassenen Anbieter. Ob ein Scan bestanden ist, regelt der ASV Program Guide: Durchgefallen ist ein Scan, wenn eine Komponente eine Schwachstelle mit einem CVSS-Basiswert ab 4,0 hat oder einen der automatischen Fehlschläge zeigt. Schwachstellen, die nur einen Denial-of-Service ermöglichen, sind davon ausgenommen. Ein nicht bestandener Scan verlangt Behebung und Rescan, bis das Ergebnis trägt.

Zwischen zwei Quartalsscans dürfen höchstens etwa 90 Tage liegen, Behebung und Rescans eingeschlossen. Über das Jahr sind vier bestandene Quartalsscans nachzuweisen, eine Lücke im Sommer reißt die Kette. Nach wesentlichen Änderungen ist nach 11.3.2.1 zusätzlich zu scannen, dafür muss es kein ASV sein. Vermeintliche Fehlalarme werden mit dem ASV geklärt und dokumentiert. Daneben stehen die internen Scans nach 11.3.1, ebenfalls vierteljährlich und seit März 2025 mit Anmeldung an den Systemen, und Penetrationstests nach 11.4 mindestens jährlich, intern und extern. Warum ein bestandener Scan wenig beweist, wenn der Umfang nicht stimmt, steht in Der bestandene Scan, der nichts beweist.

ASV-Readiness-Check: was vor dem Quartalsscan zu prüfen ist

Die meisten Überraschungen beim ASV-Scan wären vorher zu finden gewesen. Eine kurze Prüfung vor jedem Quartal:

1. Ist der Scanumfang vollständig, mit allen externen IP-Adressen und Domains, auch in der Cloud, hinter CDN und Lastverteilern?
2. Ist jede ausgenommene Komponente begründet?
3. Sind nur die Ports offen, die gebraucht werden, und keine Verwaltungsoberflächen aus dem Internet erreichbar?
4. Sind veraltete Protokolle wie SSL und frühe TLS-Versionen abgeschaltet und alle Zertifikate gültig?
5. Ist die Software auf den erreichbaren Diensten aktuell, ohne Standardseiten und Standard-Zugangsdaten?
6. Lassen WAF und Intrusion Prevention den ASV durch, damit der Scan nicht abbricht oder blind bleibt?
7. Ist klar, wer Befunde klärt und Rescans auslöst, bevor die 90 Tage ablaufen?

Der Readiness-Abgleich im PCI-DSS-Modul stellt dafür die eigene Sicht aus dem Attack Surface Management neben den Scanumfang. Was dort erreichbar ist, aber im Umfang fehlt, fällt vor dem Scan auf, nicht im Prüfungsgespräch.

Was seit März 2025 zusätzlich gilt

Mit dem Ende der Übergangsfrist wurden die zukünftigen Anforderungen aus Version 4 verpflichtend. Die wichtigsten davon:

• Mehr-Faktor-Anmeldung (8.4.2): für jeden Zugriff auf die CDE, der nicht direkt an der Konsole erfolgt, nicht nur für Administratoren und Fernzugriff. Ausgenommen sind unter anderem Konten, die sich nur mit phishing-resistenten Faktoren anmelden, siehe Identity Governance.
• Längere Kennwörter (8.3.6): mindestens zwölf Zeichen, wo das System es unterstützt.
• Skripte auf Bezahlseiten (6.4.3 und 11.6.1): ein Inventar und eine Freigabe aller Skripte, die im Browser laufen, und eine Erkennung von Manipulationen an der Bezahlseite. Für Händler mit SAQ A hat der PCI SSC diese beiden Anforderungen Anfang 2025 durch ein Eignungskriterium ersetzt.
• Schutz vor Phishing (5.4.1): technische Mechanismen gegen Phishing, etwa eine wirksame DMARC-Richtlinie für die eigenen Domains, siehe Wer in Ihrem Namen mailt.
• Automatisierte Protokollauswertung (10.4.1.1): Protokolle werden mit automatisierten Mechanismen ausgewertet, nicht von Hand durchgesehen.
• Authentifizierte interne Scans (11.3.1.2): interne Schwachstellenscans mit Anmeldung an den Systemen.

PCI DSS neben ISO 27001, NIS2 und DORA

PCI DSS ist enger und vorschreibender als ein ISMS: Er sagt nicht nur, dass Zugänge geschützt sein müssen, sondern wie lang ein Kennwort ist und wie oft gescannt wird. Inhaltlich überschneidet er sich stark mit ISO 27001, vor allem bei Zugriffskontrolle, Protokollierung, Schwachstellen und Lieferanten. Wer ein ISMS nach ISO 27001 betreibt, kann viele Nachweise einmal führen und auf beide Rahmenwerke beziehen. Zahlungsinstitute unterliegen zusätzlich DORA, andere Unternehmen möglicherweise NIS2. Ein PCI-DSS-Nachweis ersetzt keines davon.

Checkliste: PCI DSS in acht Schritten

Die Reihenfolge beginnt beim Umfang, weil jede spätere Maßnahme davon abhängt, wie groß die CDE ist.

1. Mit dem Acquirer klären, welcher Nachweis verlangt wird: SAQ und welcher Typ, oder ROC.
2. Datenflüsse aufnehmen: wo Kartendaten ankommen, wohin sie gehen, wo sie liegen.
3. Den Geltungsbereich verkleinern, durch Tokenisierung, ausgelagerte Bezahlseiten oder Segmentierung.
4. CDE, Komponenten und Ausnahmen dokumentieren, Netz- und Datenflussdiagramme pflegen.
5. Lücken gegen die 12 Anforderungen bewerten, einschließlich der seit März 2025 geltenden.
6. Quartalsscans intern und durch den ASV einplanen, mit Readiness-Check vorher und Rescans bis zum Bestehen.
7. Penetrationstests und Segmentierungstests im vorgegebenen Rhythmus durchführen.
8. Den Geltungsbereich jährlich bestätigen und SAQ oder ROC mit der Attestation of Compliance einreichen.