Der Scope: das Cardholder Data Environment (CDE)

Problem in der Praxis

Viele Organisationen beginnen PCI DSS bei den Maßnahmen statt beim Geltungsbereich. Kontrollen werden breit ausgerollt, ohne dass jemand sauber definiert hat, welche Systeme wirklich mit Karteninhaberdaten in Berührung kommen. Das Ergebnis ist ein unklarer, oft zu großer Scope.

Die Reichweite wird dabei regelmäßig unterschätzt. Karteninhaberdaten fließen selten nur durch ein System. Sie wandern durch Kassen, Zahlungsgateways, Webshops, Backoffice-Anwendungen, Logdateien, Backups und Support-Tools, manchmal auch in Tabellen oder E-Mails, in denen sie nichts zu suchen haben. Hinzu kommt der Effekt verbundener Systeme: Auch Komponenten, die selbst keine Kartendaten verarbeiten, aber mit der Kartenumgebung kommunizieren oder deren Sicherheit beeinflussen, können in den Geltungsbereich fallen. Ein flaches, ungetrenntes Netz zieht so oft die halbe IT in den Scope. Spätestens wenn ein Acquirer oder Prüfer Belege verlangt, wird sichtbar, dass der Geltungsbereich nie bewusst abgegrenzt wurde.

CISO-Einordnung

Aus Management-Sicht ist der Scope die wichtigste Stellschraube für Aufwand und Risiko. Drei Fragen stehen im Mittelpunkt:

• Wo entstehen, fließen und ruhen Karteninhaberdaten tatsächlich?
• Welche Systeme und Prozesse müssen deshalb im CDE liegen?
• Welche Systeme lassen sich durch klare Trennung glaubhaft aus dem Geltungsbereich heraushalten?

Wichtig ist die Unterscheidung der Datenarten. Karteninhaberdaten mit der Kartennummer (PAN) als Kern sind etwas anderes als Sensitive Authentication Data (SAD); SAD darf nach der Autorisierung grundsätzlich nicht gespeichert werden. Wer Daten gar nicht erst speichert oder sie früh unkenntlich macht, verkleinert Scope und Risiko zugleich. Die exakten Datenelement-Definitionen sind Bestandteil des PCI-DSS-Textes und beim PCI SSC nachzulesen.

Der zweite Hebel ist Segmentierung. Eine wirksame Trennung der Kartenumgebung vom übrigen Netz ist das anerkannte Mittel zur Scope-Reduktion. Sie ist im Standard nicht zwingend vorgeschrieben, aber ohne sie gilt im Zweifel das gesamte Netz als CDE. Damit die Trennung den Scope tatsächlich begrenzt, muss sie belastbar sein und nachgewiesen werden, etwa durch Penetrationstests zur Wirksamkeit der Segmentierung.

Der Validierungsaufwand hängt schließlich an Rolle und Volumen. PCI DSS unterscheidet Merchants und Service Provider und kennt für Händler abgestufte Level nach jährlichem Transaktionsvolumen. Je nach Level erfolgt der Nachweis über einen Self-Assessment Questionnaire (SAQ) oder einen umfassenden Report on Compliance (ROC), in der Regel durch einen Qualified Security Assessor (QSA), begleitet von einer Attestation of Compliance (AOC). Die konkreten Schwellenwerte und Validierungspflichten werden von den einzelnen Card Schemes definiert und unterscheiden sich je Marke; sie sind beim jeweiligen Scheme und Acquirer zu prüfen.

Umsetzungsperspektive

Sinnvoll ist eine Reihenfolge vom Datenfluss zum Geltungsbereich und erst dann zu den Maßnahmen:

• Karteninhaberdaten end-to-end kartieren: Eingang, Verarbeitung, Übertragung, Speicherung, Löschung. Auch Nebenwege wie Logs, Backups, Monitoring und Support gehören dazu.
• CDE ableiten: alle Systeme, Prozesse und Personen markieren, die diese Daten berühren, sowie verbundene und sicherheitsbeeinflussende Systeme.
• Scope reduzieren: prüfen, welche Daten vermeidbar, früher unkenntlich zu machen oder auszulagern sind, und welche Systeme durch Segmentierung getrennt werden können.
• Auslagerung bewerten: Dienstleister, P2PE-Lösungen oder Tokenisierung können Datenflows aus der eigenen Umgebung heraushalten, verschieben Verantwortung aber nicht vollständig.
• Geltungsbereich festschreiben und regelmäßig bestätigen: Der Scope ist jährlich und bei wesentlichen Änderungen neu zu prüfen.

Auslagerung reduziert den eigenen Scope nur, wenn die Schnittstellen sauber getrennt sind und die Verantwortungsteilung mit dem Dienstleister dokumentiert ist. Tokenisierung und starke Verschlüsselung sind wirksame Mittel, um den Umgang mit Klartext-Kartendaten und damit den Geltungsbereich einzugrenzen. Verbindliche Detailbedingungen dafür regelt der Standard selbst.

Typische Fehler

1. Mit Maßnahmen beginnen, bevor der Datenfluss und damit der Scope verstanden ist.
2. Den Geltungsbereich auf offensichtliche Zahlungssysteme verengen und Nebenwege wie Logs, Backups und Support übersehen.
3. Segmentierung annehmen, aber nicht testen, sodass die Trennung den Scope rechtlich-faktisch nicht reduziert.
4. Verbundene und sicherheitsbeeinflussende Systeme ignorieren und so den realen CDE unterschätzen.
5. Auslagerung mit Verantwortungsabgabe verwechseln und die Verantwortungsteilung mit Dienstleistern nicht dokumentieren.
6. Den Scope einmal definieren und nicht laufend an neue Prozesse, Produkte und Integrationen anpassen.

Risiken und Trade-offs

Ein zu eng gezogener Scope ist gefährlich: Werden Systeme fälschlich ausgeklammert, bleiben Kartendaten ungeschützt, und im Prüf- oder Schadensfall fällt die Lücke auf. Ein zu breit gezogener Scope ist teuer: Mehr Systeme bedeuten mehr Kontrollen, mehr Nachweise und höhere laufende Kosten.

Segmentierung verlagert Aufwand. Sie reduziert den Geltungsbereich, erzeugt aber selbst Aufwand für Aufbau, Pflege und wiederkehrende Wirksamkeitsnachweise. Eine schlecht gepflegte Segmentierung gibt trügerische Sicherheit, weil sie auf dem Papier trennt, im Betrieb aber durchlässig ist.

Auslagerung verschiebt Risiko, beseitigt es nicht. Verantwortung für die Auswahl, Steuerung und vertragliche Absicherung der Dienstleister bleibt im Haus. PCI DSS ist zudem kein Gesetz, sondern wird vertraglich über Acquirer und Card Schemes verbindlich; Verstöße können zu Vertragsstrafen, höheren Gebühren oder im Extremfall zum Entzug der Kartenakzeptanz führen.

Entscheidungspunkte

• Welche Geschäftsprozesse benötigen überhaupt den Umgang mit Karteninhaberdaten, und welche können darauf verzichten?
• Welche Datenflows lassen sich durch Tokenisierung, P2PE oder Auslagerung aus der eigenen Umgebung entfernen?
• Wie tief soll segmentiert werden, und wer verantwortet die laufende Wirksamkeit der Trennung?
• Welche Rolle (Merchant oder Service Provider) und welches Level liegt vor, und welcher Nachweisweg ergibt sich daraus?
• Wer hält den Scope aktuell, wenn neue Systeme, Produkte oder Integrationen hinzukommen?

Praktische Empfehlungen

1. Beginnen Sie jede PCI-DSS-Initiative mit einem belastbaren Datenfluss-Diagramm der Karteninhaberdaten, nicht mit einer Maßnahmenliste.
2. Definieren Sie den CDE bewusst und schriftlich, inklusive verbundener und sicherheitsbeeinflussender Systeme.
3. Reduzieren Sie den Scope zuerst durch Datenvermeidung und frühere Unkenntlichmachung, dann durch Segmentierung und Auslagerung.
4. Lassen Sie die Wirksamkeit der Segmentierung regelmäßig prüfen und dokumentieren, nicht nur einmalig behaupten.
5. Behandeln Sie den Scope als lebenden Gegenstand mit jährlicher Bestätigung und einem Trigger bei wesentlichen Änderungen.
6. Klären Sie Level, Nachweisweg und Validierungspflichten konkret mit Acquirer und Card Scheme, statt von einheitlichen Schwellen auszugehen.

Relevante Normreferenzen

• PCI DSS (PCI Security Standards Council), aktuelle Version v4.0.1 (veröffentlicht am 11.06.2024): Referenz für Scope, CDE-Definition, Segmentierung und Validierung. Verbindliche Anforderungen, Datenelement-Definitionen und Testverfahren ausschließlich der Originalquelle entnehmen.
• ISO/IEC 27001: Referenz für ein risikobasiertes ISMS mit breiterem Geltungsbereich; hohe Control-Überschneidung, aber kein Ersatz für PCI DSS.
• NIST Cybersecurity Framework und NIST SP 800-53 / 800-63: Referenz als konzeptionelle Mapping-Ebene für Schutz- und Zugriffsfunktionen; kein offizielles 1:1-Mapping durch den PCI SSC.