Wie ist die Gültigkeit der Versionen 3.2.1 und 4.0 geregelt?

31.03.2022 bis 31.03.2024
In der Übergangszeit können Zertifizierungen nach PCI DSS v3.2.1 oder v4.0 erfolgen. Gut zu wissen: Der Nachweis nach v3.2.1 ist auch nach Abschluss noch ein Jahr gültig.

Ab 01.04.2024
Ein Nachweis nach PCI DSS v3.2.1 ist ab sofort nicht mehr möglich. Zertifizierungen müssen nun in jedem Fall nach v4.0 durchgeführt werden.

Verliert mein in PCI v3.2.1 abgeschlossener SAQ am 01.04.2024 seine Gültigkeit?

Nein, das ist nicht der Fall. Der Nachweis nach v3.2.1, solange er bis zum 31.03.2024 abgeschlossen wurde, bleibt auch über das Datum hinaus für 12 Monate gültig. Somit wäre es rein formal möglich, dass Ihr Unternehmen bis zum 31.03.2025 mit v3.2.1 seine PCI Compliance nachweist.

Gibt es komplett neue Anforderungen, die sofort umgesetzt werden müssen?

Auch wenn es komplett neue Anforderungen gibt, sind diese erst nach einer Implementierungsphase ab dem 01.04.2025 verpflichtend umzusetzen. Die sogenannten „Future-Dated Requirements“ gelten bis zum 31.03.2025 als Best-Practice und sind in dem Zeitraum bis zum 31.03.2025 optional. Ab diesem Stichtag sind alle neuen Anforderungen des PCI DSS v4.0 verbindlich umzusetzen.

Kann es sein, dass ich nach v3.2.1 keine ASV Scans durchführen musste, jedoch mit der neuen v4.0 sich eine Scanpflicht für mein Unternehmen ergibt?

Ja, dies kann durchaus sein.

Auch wenn sich die Einstufung in die SAQ Typen mit PCI v4.0 nicht geändert hat, gibt es in Bezug auf den SAQ Typen A eine signifikante Änderung in Bezug auf die Durchführung von ASV Scans: Mit Version 4.0 wird die Anforderung zur Durchführung von ASV Scans in den SAQ aufgenommen.
Fachlich ist das darin begründet, dass der PCI-Prüfumfang bei Kartenzahlungen auf die Webseite selbst erweitert wurde. Somit rückt die Checkout-Seite im Webshop, die den Absprung zum PCI zertifizierten Dienstleister bei der Kartenzahlung einleitet, in den Prüfumfang von PCI DSS.

Dies hat Auswirkungen auf alle Händler, die im E-Commerce die Kartenzahlung bzw. -eingabe auf der eigenen Webseite akzeptieren. Gemäß den Vorgaben rückt die Sicherheit des Absprungpunkts auf der Bezahlseite (Payment Page) beim Händler in den PCI-Prüfumfang. Der Interpretation nach bedeutet das für jeden E-Commerce Händler, der die Eingabe von Kartendaten auf der eigenen Webseite erlaubt, dass sein Webshop mittels ASV Scans alle 90 Tage auf externe Schwachstellen zu prüfen ist.

Dies ist der Entwicklung geschuldet, dass die Checkout-Seite mit dem Link zur Kartenzahlung für Angriffe Dritter immer mehr in den Fokus rückte. Über Web-Skimming und unsicheren Payment Page Skripten versuchen Angreifer bereits vor der Weiterleitung des Karteninhabers auf die Seiten des PCI zertifizierten Partners in die Abwicklung einzugreifen.

Was versteht man unter einer Payment Page?

Der Definition nach handelt es sich um ein Webformular, in das der Karteninhaber die vollständige Kartennummer (PAN) einträgt. Bezogen auf eine Abwicklung im E-Commerce geht es um die Eingabemaske, in die der Karteninhaber bei der Zahlung die Kartennummer eingibt.

Was versteht man unter Payment Page Skripten?

In PCI v4.0 taucht die Bezeichnung in der neuen Anforderung 6.4.3 auf, die als sogenanntes Future Dated Requirement erst ab dem 01.04.2025 verpflichtend umgesetzt sein muss. Dort geht es um Skripte, die auf der Bezahlseite eingebunden sind. Diese können vom Händler selbst, dem Payment Service Provider oder von Drittanbietern kommen. Von den Funktionen her können die Skripte z.B. im Rahmen des Payments die Generierung des iframes in SAQ A betreffen. Es ist auch möglich, dass es sich um Skripte handelt, die die korrekte Eingabe von Kartendaten prüfen oder für Werbezwecke, Statistiken bzw. Design eingesetzt werden. Es sind noch viele weitere Funktionen denkbar.

All diesen Skripten ist gemein, dass sie auf der Seite extern geladen und/oder ausgeführt werden können und sie somit einen relevanten Faktor für die Sicherheit bei der Kartenzahlung darstellen.

Welches Risiko stellt die Verwendung von Payment Page Skripten dar und welchen Ansatz gibt es, sich dagegen zu schützen?

Es besteht die Gefahr, dass diese scheinbar harmlosen Skripte von Angreifern genutzt werden, um bösartige Skripte hochzuladen und unbemerkt zu verwenden. Bösartige Skripte könnten dann die Kartendaten aus dem Browser der Kunden auslesen und herausfiltern.

Um dem entgegen zu wirken, reduzieren Sie am besten die Anzahl der Skripte, die manipuliert werden könnten: Stellen Sie sicher, dass nur Skripte verwendet werden, die für die Funktion Ihrer Zahlungsseite notwendig sind und deren Relevanz sie nachvollziehen können.

Zudem sollte sichergestellt werden, dass unnötige Skripte nicht ohne entsprechende Genehmigung der Geschäftsleitung zur Zahlungsseite hinzugefügt werden.

Welche Sicherheit rund um die Payment Page Skripte muss gewährleistet sein?

Die Sicherheit von Payment Page Skripten findet in den Anforderungen 6.4.3 sowie 11.6.1 Anwendung:

Anforderung 6.4.3
Es wird vorgeschrieben, dass nur absolut notwendige Skripte auf der Payment Page ausgeführt werden sollen. Um eine sichere Verwaltung zu gewährleisten, ist es erforderlich, dass die Skripte inventarisiert, autorisiert und auf Integrität geprüft werden. Für jedes Skript muss zusätzlich begründet werden, warum es auf der Payment Page eingebunden wird.

Anforderung 11.6.1
Es wird ein Verfahren gefordert, welches unautorisiert vollzogene Änderungen am Inhalt der Payment Page und/oder des http-Headers frühzeitig erkennt. Um das Ziel zu erreichen, muss die Prüfung periodisch erfolgen. Bei Auffälligkeiten muss zeitgleich automatisiert ein Alarm beim Händler/Service Provider eingehen.

Wo kann ich mehr über die Neuerungen rund um die PCI DSS Version 4.0 erfahren?

Unsere Experten haben die Neuerungen, die PCI DSS v4.0 mit sich bringt, in Video- und Blog-Beiträgen für Sie zusammengefasst. Über weitere Neuerungen halten wir Sie daher mit unseren PCI News-Beiträgen auf unserer Unternehmens-Webseite auf dem Laufenden.