PCI DSS 4.0: Das Warten ist vorbei

Nach über vier Jahren Entwicklungszeit – der erste RFC startete bereits Ende 2017 – ist Ende März 2022 die lang erwartete Version 4.0 des „Payment Card Industry Data Security Standard“ (PCI DSS) veröffentlicht worden. DSS 4.0 ist das erste Major-Release seit 2013. Die lange Entwicklungszeit und der Abstand zur vorherigen Hauptversion lassen schon erahnen, dass die neue Version signifikante Änderungen und Neuerungen mit sich bringt.

Eine Aktualisierung war auch dringend notwendig, denn selbst wenn der Standard vom Grundprinzip her immer technologieunabhängig war, haben sich die Informationstechnik und auch die Angriffe auf die IT seit 2013 doch massiv geändert – zum Beispiel nutzen heute, anders als damals, viele Kreditkarten-Dienstleister und Händler cloudbasierte Lösungen. Die neue Version PCI DSS 4.0 versucht, den Sicherheitsbedarf der Kreditkartenindustrie nach aktuellem Stand der Technik zu unterstützen und auch der geänderten Bedrohungslage gerecht zu werden. Darüber hinaus haben sich in der Zwischenzeit weitere wichtige IT-Sicherheitsstandards etabliert –auch hier versucht der DSS 4.0 diese Entwicklung mit einer höheren Flexibilität bei Anforderungen und Prüfmethoden zu unterstützen.

Mittlerweile ist zwar die deutsche Übersetzung des Standards verfügbar – leider enthält aber auch die neue deutsche Fassung viele Übersetzungsfehler. Die Autoren empfehlen daher weiterhin, wenn möglich ausschließlich mit der englischsprachigen Originalversion zu arbeiten. Aus diesem Grund verwendet auch dieser Artikel hauptsächlich die englischen Originalbegriffe aus dem Standard.

Umsetzungszeitplan

PCI DSS 4.0 wurde am 31. März 2022 veröffentlicht. Wie in der Vergangenheit bekommen Unternehmen jedoch eine Übergangsfrist zur Umsetzung der neuen Anforderungen: Zunächst einmal kann jedes Unternehmen bis zum 31. März 2024 selbst entscheiden, ob es sich weiterhin nach DSS 3.2.1 oder direkt nach 4.0 zertifizieren lassen will. Generell werden Zertifizierungen allerdings erst ab Sommer 2022 möglich sein, da alle Auditoren noch ein spezielles Training absolvieren müssen, das voraussichtlich erst im Juni/Juli zur Verfügung gestellt wird.

Wie in den DSS-Veröffentlichungen zuvor, unterteilen sich die Änderungen im neuen DSS4.0 in drei verschiedene Kategorien: Evolving Requirement, Clarification/Guidance und Structure/Format. Der Großteil der neuen Anforderungen wird erst ab dem 31. März 2025 verpflichtend. Bis dahin werden sie als Best Practice verstanden und müssen bei einer Zertifizierung nach Version 4.0 noch nicht zwingend erfüllt werden.

Insgesamt sind die definierten Zeiträume, bis Unternehmen zwingend alle DSS-4.0-Anforderungen umsetzen müssen, sehr großzügig gewählt (vgl. Abb. 1). Aufgrund der langen Zeit seit dem letzten Major-Release und der großen Anzahl an Neuerungen empfehlen die Autoren allerdings allen betroffenen Unternehmen, sich zeitnah mit den Anforderungen zu befassen.

Allgemeine Änderungen

Im Folgenden werden zunächst wichtige grundlegende Änderungen im neuen Standard beschrieben. Generell unterscheidet der PCI DSS weiterhin an einigen Stellen zwischen Händlern (Merchants) und Bezahldienstleistern (Service-Providers). 53 von 64 neuen Anforderungen sind jedoch für alle Arten von PCI relevanten Unternehmen anwendbar – nur 11 Anforderungen gelten ausschließlich für Bezahldienstleister und nicht für Händler.

Security als kontinuierlicher Prozess

Obwohl der PCI DSS3.2.1 einen besonderen Fokus auf die sogenannten Business-as-usual-(BAU)-Prozesse legt, stand bei der Entwicklung des PCI DSS 4.0 weiter die Aufrechterhaltung der PCI-Compliance über das gesamte Jahr hinweg im Mittelpunkt.

Ein Beispiel hierfür ist die Erweiterung beim Thema Scoping, also die Definition des Audit-Umfangs: Dies ist seit jeher eine große Herausforderung in komplexen Kreditkartenumgebungen. Seit 2016 gibt es bereits ein separates Informationsdokument (Information-Supplement) vom PCI Council zum Thema Scoping, das aber nur Empfehlungscharakter besitzt. Viele Aspekte dieses Dokuments werden nun durch die Übernahme in den offiziellen Standard verpflichtend.

Ein wichtiger neuer Aspekt sind die jährlichen (für Bezahldienstleister sogar halbjährlichen) oder nach bedeutenden Änderungen an der Umgebung geforderten Scope-Reviews. Die Ergebnisse des internen Scope-Reviews müssen offiziell dokumentiert und dem Auditor während der jährlichen Rezertifizierung nachvollziehbar dargelegt werden.

Customized Approach versus Defined Approach

PCI DSS war schon immer ein sehr konkreter IT-Sicherheitsstandard – neben klar definierten Requirements für nachweispflichtige Organisationen enthält er ebenso klar definierte Testing-Procedures für die Auditoren. Diese Vorgehensweise ist Fluch und Segen zugleich: Auf der einen Seite helfen konkrete Anforderungen Unternehmen bei der Umsetzung und die Testing-Procedures sorgen für eine gleichbleibende hohe Qualität der Audit-Ergebnisse. Allerdings gibt es mittlerweile viele Unternehmen, die verschiedenen IT-Sicherheitsanforderungen (ISO 27001, SOC, § 8a BSIG usw.) unterliegen und denen die Erstellung eines einheitlichen Control-Sets durch die eng definierten DSS-Anforderungen erschwert wird.

Dadurch wird PCI DSS heute häufig als Insellösung für die Kreditkartendatenumgebung genutzt. Um gerade großen Unternehmen mehr Flexibilität bei der Umsetzung des DSS zu geben, werden neben dem Traditional Approach – in DSS 4.0 auch Defined Approach genannt – eine neue Art der Anforderungsdefinition und entsprechende Möglichkeiten zur Prüfung eingeführt: der Customized Approach.

Mit dem Customized Approach kann ein Unternehmen für fast alle Anforderungen (bis auf wenige Ausnahmen) eigene Controls erstellen, anstatt die im Defined Approach vorgegebenen Controls umzusetzen. Wichtig ist dabei, dass das Objective, also die Intention hinter der Anforderung, auch mit diesen individuell definierten Controls erfüllt wird. Um das zu überprüfen, muss der jeweilige Qualified Security-Assessor (QSA) geeignete Testing-Procedures aus den Controls ableiten.

Der Prozess hierfür ist detailliert beschrieben und sehr komplex. Das PCI Council empfiehlt daher auch, dass nur Unternehmen mit IT-Sicherheitsorganisationen, die über entsprechende Ressourcen verfügen, dieses Werkzeug umfassend nutzen sollten. Trotzdem bietet der neue Customized Approach Unternehmen endlich die benötigte Flexibilität, um mehrere Sicherheitsstandards miteinander zu verzahnen und bereits vorhandene IT-Sicherheitszertifizierungen besser nutzen zu können.

Neue Security-Anforderungen

Generell wurden viele Anforderungen aktualisiert und angepasst – die Grundstruktur des Standards hat sich allerdings nicht geändert: Es gibt weiterhin 12 Hauptanforderungen, die vom Themenbereich her grundlegend gleichgeblieben sind (vgl. Tab. 1).

Der folgende Abschnitt geht auf ausgewählte neue oder geänderte Anforderungen ein, die aus Sicht der Autoren für Unternehmen hauptsächlich relevant sind. Sämtliche hier aufgeführte Anforderungen sind bis zum 31. März 2025 als Best Practices definiert und müssen erst danach verpflichtend umgesetzt werden.

Auf alle 64 neuen Anforderungen einzugehen, würde den Rahmen eines Fachbeitrags sprengen – die Autoren empfehlen dennoch sämtlichen betroffenen Unternehmen dringend, sich frühzeitig umfassend mit allen Details des neuen Standards zu beschäftigen.

Kopieren der Primary Account-Number (PAN)

Der Schutz der Kreditkartennummer (Primary Account-Number – PAN) ist seit jeher das primäre Ziel des PCI DSS. Im DSS 4.0 wird nun eine neue Anforderung ergänzt, durch die das Kopieren der PAN im Rahmen eines Remotezugriffs technisch unterbunden werden muss, sofern für den jeweiligen Benutzer kein Business-Need für diese Funktion besteht.

Da Standardlösungen für den Zugriff auf Systeme, wie RDP oder SSH, diese Funktionalität nicht „out of the
Box“ mit sich bringen, sind hierfür neue technische Lösungen zu evaluieren und zu implementieren. Generell bietet es sich an, per Remotezugriff ohnehin nur den Zugriff auf ausmaskierte Daten zu erlauben. Aber häufig ist eine Unterscheidung für einzelne Benutzer auf dieser Ebene nicht möglich – und daher muss der Zugriff über Einschränkungen der Remotezugriffsverbindung umgesetzt werden, beispielsweise durch Deaktivierung des Clipboards und der Downloadfunktionen beim Remotezugriff.

Multi-Factor-Authentication (MFA)

Schon im Rahmen des letzten Minor-Updates wurde die Thematik zur Nutzung von Multi-Factor-Authentication (MFA) im DSS weiter verschärft. PCI DSS 4.0 führt nun die vollständige Verpflichtung zur Nutzung von MFA beim Zugriff auf das Cardholder-Data-Environment (CDE) ein. Dies betrifft sowohl den Remotezugriff, wie bereits in PCI DSS 3.2.1, als auch den Zugriff von internen Systemen aus und gilt für Benutzer mit und ohne administrative Rechte.

Es wird auch noch einmal explizit betont, dass MFA für alle Arten von Zugriffen (Anwendungs-, Netzwerk- und System-Ebene) gilt, wobei ein genereller MFA-Zugriff, beispielsweise auf Netzwerk-Ebene, die anderen Ebenen mit einschließt, sofern damit alle Zugriffe abgedeckt werden. Auch Cloudumgebungen inklusive deren Web-Zugänge müssen nun ebenfalls verpflichtend auf MFA umgestellt werden. An die MFA-Systeme selbst werden darüber hinaus zusätzliche Anforderungen gestellt, beispielsweise eine Resilienz gegen Replay-Angriffe.

Keyed Hashes

Hash-Funktionen werden im Kreditkartenbereich häufig für Suchfunktionen verwendet, indem man Kreditkartendaten in gehashter Form speichert. Hiermit wird eine Suche nach einer bestimmten Kartennummer („Hat Kunde XYZ bereits eine Zahlung im Webshop getätigt?“) vereinfacht.

Bislang war die Nutzung sogenannter Salts beim Einsatz von Hashfunktionen nur empfohlen – im neuen Standard geht das PCI Council nun einen Schritt weiter und führt die Verpflichtung zur Nutzung von Keyed Cryptographic Hashes ein. Die dabei verwendeten kryptografischen Schlüssel müssen nun mit den gleichen hohen Key-Management-Anforderungen geschützt werden, wie alle anderen Schlüssel. Hierfür sind bei bestehenden Lösungen sowohl die Hashfunktionen als auch das komplette kryptografische Schlüsselmanagement umzustellen.

Disk-Verschlüsselung

Auch wenn eine Verschlüsselung der Kreditkartendaten auf Festplattenebene schon immer als ein sehr schwacher Schutz angesehen wurde und fast überall mittlerweile eine Verschlüsselung der Daten auf Applikations- oder zumindest Datenbankebene eingesetzt wird, ist die Disk-Verschlüsselung häufig noch immer in Legacy-Umgebungen zum Einsatz gekommen.

Diese Ausweichmöglichkeit wurde nun im DSS 4.0 (endlich) beseitigt und Disk-Verschlüsselung alleine wird nicht länger als eine Möglichkeit zum Schutz der sensiblen Kreditkartendaten betrachtet. Erlaubt bleibt jedoch der Einsatz von Disk-Encryption bei der Nutzung elektronischer Wechseldatenträger.

E-Commerce-Sicherheit

Die größten Fraud-Rates verzeichnet die Kreditkartenzahlung weiterhin im E-Commerce-Bereich: Dort ist es für Angreifer vermeintlich am einfachsten, eine große Menge an Kartendaten abzugreifen. Durch PCI DSS 3.x wurde im Rahmen der Risikoabwägung die Nutzung von iFrames oder Redirect-Lösungen in Webshops forciert. Dennoch lassen sich auch die genannten Verfahren bei einem erfolgreichen Angriff auf den Händler-Webserver aushebeln – trotz Einsatz eines PCI-zertifizierten Dienstleisters.

Um für noch mehr Sicherheit im E-Commerce zu sorgen, wurden nun gleich mehrere neue Anforderungen im PCI DSS 4.0 ergänzt: Zum einen ist die Nutzung von Bezahl-Skripten reglementiert, wo nun jedes Skript explizit autorisiert und inventarisiert werden muss. Zusätzlich ist die Integrität der Skripte sicherzustellen. Hintergrund ist, dass in der Vergangenheit erfolgreich Angriffe, beispielsweise über veränderten Javascript-Code, stattgefunden haben, der dann in die Payment-Seite geladen wird.

Eine weitere Anforderung deckt das Angriffsszenario ab, dass trotz des Einsatzes von iFrames oder Redirect-Technology der zugrunde liegende Webserver von Angreifern erfolgreich kompromittiert wird und dann der Content der umliegenden Seite so manipuliert wird, dass sich dennoch Kreditkartendaten abgreifen ließen. Hierfür muss zukünftig bei den Webshop-Betreibern eine Lösung zur Überwachung der Integrität technisch implementiert werden, welche die HTTP-Header sowie Inhalte der Bezahlseiten überwacht und Veränderungen an der Integrität der Seiteninhalte meldet.

Gängige Lösungen hierfür sind der Einsatz einer Content-Security-Policy (CSP) und der Subresource-Integrity (SRI)-Funktion in den Browsern der Endkunden. Beide Verfahren sind aber noch nicht in der Breite als Standardlösungen im Einsatz und es bleibt abzuwarten, wie praktikable Lösungen für die genannten Themen aussehen.

Technische Benutzer-Accounts

Die Nutzung technischer Benutzer-Accounts (z. B. Datenbank- oder Applikations-User) wurde bislang im PCI DSS nur am Rande reglementiert. Technische Benutzerzugänge stellen aber erfahrungsgemäß ein hohes Risiko dar: Sie haben üblicherweise sehr umfassende Rechte und sind zum anderen häufig auch vom Monitoring ausgenommen, weil sie ansonsten die zentrale Log-Lösung mit der schieren Anzahl an Einträgen an ihre Grenzen bringen würden.

Mit DSS 4.0 ändert sich die Bewertung umfassend und es werden technische und organisatorische Kontrollen gefordert. Die neuen Anforderungen decken verschiedene Bereiche rund um die Nutzung technischer Benutzerzugänge ab. Hier fordert der Standard beispielsweise strenge Genehmigungsprozesse für das Anlegen von technischen Benutzern; und auch die Nutzung von „hardcoded“ Passwörtern in Skripten, Software-Code et cetera wird nun explizit verboten.

Phishing

Das Thema Phishing wurde in den bisherigen DSS Versionen nicht adressiert und in DSS 4.0 an zwei Stellen ergänzt: zum einen im Bereich Security-Awareness-Training, wo nun explizit auch das Thema Phishing Bestandteil der Maßnahmen sein muss – und zum anderen müssen auch technische Anti-Phishing-Maßnahmen umgesetzt werden. Beispielhaft wird hier eine Mischung aus Anti-Spoofing-Maßnahmen (z. B. Domainbased Message Authentication, Reporting & Conformance – DMARC, Sender-Policy-Framework – SPF sowie Domain-KeysIdentified-Mail – DKIM) sowie server- und clientbasierter Anti-Malware-Lösungen genannt. Viele dieser Themen sollten allerdings bei den meisten Unternehmen bereits gängige Praxis sein und stellen vermutlich keine große Herausforderung bei der Umsetzung dar.

Vulnerability-Scanning und -Management

Weitere spannende Neuerungen wurden im Bereich Vulnerability-Scanning und -Management ergänzt. Die wichtigste ist die zukünftige Verpflichtung, authentifizierte Scans im internen Netz zu nutzen. Viele Schwachstellenscanner bieten schon heute die technische Möglichkeit an, sich mit hinterlegten Zugängen in die Systeme einzuloggen. Da diese Möglichkeit aber nach Einschätzung der Autoren noch nicht großflächig in Unternehmen genutzt wird, bedarf dies einer entsprechenden Planung und Tests auf Unternehmensseite.

Zusätzlich müssen in DSS 4.0 nun alle von den Scannern gefundenen Schwachstellen behandelt werden –unabhängig ihrer Risikoeinstufung nach Common Vulnerability-Scoring-System (CVSS). Generell ist es zwar weiterhin erlaubt, identifizierte Schwachstellen mit einer geringen Risikoeinstufung auch mit geringer Priorität zu behandeln – aber allein das letztendliche Handling sämtlicher Schwachstellen und deren Risikobewertung und Nachverfolgung der Aktivitäten dürften viele Unternehmen vor neue Herausforderungen stellen.

Fazit

PCI DSS 4.0 wird dem lang erwarteten, großen Wurf gerecht – die Neuerungen sind zeitgemäß und schließen in vielen Fällen Lücken, die in der Sicherheitsarchitektur von Kreditkartenumgebungen im Laufe der letzten Jahre identifiziert wurden. Dass praktisch alle neuen Anforderungen erst ab dem 1. April 2025 umgesetzt sein müssen, hinterlässt jedoch einen faden Beigeschmack: Bei den von vielen Unternehmen bekanntermaßen knapp kalkulierten Budgets für die IT-Sicherheit besteht so die Gefahr, dass viele sinnvolle Investitionen in die Verbesserung der IT-Sicherheit erst im Jahr 2024 eingeplant werden.

Generell muss sich das PCI Council auch die Frage stellen, ob es sich noch einmal erlauben kann, eine derart lange Zeit bis zum nächsten Major-Release-Update verstreichen zu lassen – „nach dem Update ist vor dem Update!“ und es bleibt abzuwarten, ob nicht in naher Zukunft schon wieder ein Minor-Update notwendig sein wird. Darüber hinaus bleibt die Frage offen, ob es der Kreditkartenindustrie und dem PCI Council gelingt, die vielfältig sinnvollen und strengen Anforderungen des PCI DSS 4.0 durch die Einführung des Customized Approach auch für andere, nicht-kreditkartenrelevante Bereiche attraktiv zu machen – das würde aus Sicht der Autoren einen echten Gewinn an mehr Sicherheit in Unternehmen bringen.

Zwischenzeitlich wurden vom PCI Council auch die sogenannten Selbstauskunftsfragebögen (Self-Assessment-Questionnaires, SAQs) in der neuen Version 4.0 veröffentlicht (siehe www.pcisecuritystandards.org/pci_security/completing_self_assessment). Diese sind gerade für Händler sehr wichtig, weil dort der Compliance-Nachweis typischerweise anhand der szenariobasierten Fragebögen erfolgt. Auch dort finden sich teilweise signifikante Änderungen wieder – in den nächsten Monaten bleibt abzuwarten, wie sich diese Änderungen auf die kreditkartenakzeptierenden Händler auswirken werden.

Christopher Kristes ist Vorstand für den Bereich Security Audits & PCI bei der usd AG und als Auditor und QSA tätig. Torsten Schlotmann ist Leiter für den Bereich PCI Security Services bei der usd AG und als QSA und PCI Secure Software Assessor tätig.