Wenn Kartenzahlungen vollständig an einen PCI DSS-konformen Zahlungsdienstleister ausgelagert werden, kann in den meisten Fällen der "kleine" SAQ A (Fragebogen) angewendet werden.
Zusätzliche Anforderungen gelten für Webserver von Händlern, die Seite(n) hosten, die das Zahlungsformular mit einem URL redirect oder per iFrame einbinden und somit die Eingabe der Kartendaten an einen PCI DSS zertifizierten Dienstleister ausgelagert haben.
Einige wichtige neue Anforderungen im SAQ (Self Assessment Questionaire) A:
| Anforderung: | Erklärung: |
|---|---|
| Anforderung 6.3.1 | Ermittelte neue/kritische Sicherheitsschwachstellen sind vom Unternehmen (Händler) einer Risikoeinstufung nach „Industry Best Practice“ zu klassifizieren und die Auswirkungen sind zu dokumentieren. |
| Anforderung 11.3.2 | Externe Schwachstellenscans müssen durch einen akkreditierten ASV (Approved Scanning Vendor = für Sicherheitsscans zugelassene Security Unternehmen) mindestens einmal alle 3 Monate durchgeführt werden. |
| Anforderung 8.4.2 | Die Multi-Faktor Authentifizierung ist für Personen mit Zugriff auf die Systeme mit Kartendaten verpflichtend (SAQ A-EP). Erst ab dem 01.04.2025 verpflichtend |
| Anforderung 8.3.6 | Passwörter müssen mindestens 12 Stellen (alphanumerisch) lang sein um die Benutzerkonten besser zu schützen. Erst ab dem 01.04.2025 verpflichtend |
Mit Version 4.0 wird die Anforderung zur Durchführung von externen Schwachstellenscans für SAQ A verpflichtend.
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 (Service Provider) 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.
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 unsichere Payment Page Skripte versuchen Angreifer bereits vor der Weiterleitung des Karteninhabers auf die Seiten des PCI zertifizierten Partners in die Abwicklung einzugreifen.
Empfehlung an Unternehmen/Händler/Kunden:
Abschluss eines Vertrages mit einem zugelassenen Security Dienstleistungsunternehmen für externe Schwachstellenscans (ASV = Approved Scanning Vendor) wie z.B. das Security Partner Unternehmen der PAYONE, die usd AG.
PCI 4.0 fordert mehr Sicherheit rund um Bezahlseiten
Was versteht man unter einer Payment Page?
Der Definition nach handelt es sich um ein Webformular (Eingabemaske), in das der Karteninhaber die vollständige Kartennummer (PAN) einträgt.
Was versteht man unter Payment Page Skripten?
In PCI Version 4.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 oder die Steuerung des Redirects 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.
Welche Sicherheit rund um die Payment Page Skripte muss gewährleistet sein?
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.
Die Sicherheit von Payment Page Skripten findet in den Anforderungen 6.4.3 sowie 11.6.1 Anwendung:
| Anforderung: | Erklärung: |
|---|---|
| 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. |
Empfehlung an Unternehmen/Händler/Kunden:
Reduzieren Sie 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.
Für Fragen und weitere Informationen steht Ihnen das PAYONE PCI Team unter der
E-Mail Adresse: pci-competence-center@payone.com zur Verfügung.
Wünschen Sie weitere Informationen zu PCI DSS v4.0? Unser PCI Security Partner usd AG hat für Sie alles Wissenswerte in Blogbeiträgen und Webinaren aufbereitet.
Sie benötigen individuelle PCI DSS Beratungsleistungen (kostenpflichtig)? Unseren PCI Security Partner usd AG erreichen Sie unter:
E-Mail: vertrieb@usd.de