Die Uhr des PCI DSS 3.2.1 hat die Mitternachtsstunde erreicht ... Sind Sie bereit für 4.0?

Sonntag, 31. März 2024, ein weltweit wichtiges Datum ist gekommen und gegangen. Warum sage ich das? Für alle Organisationen, die Verbraucherzahlungen entgegennehmen, ist dies das Datum, an dem der Konformitätsstandard PCI DSS 3.2.1 außer Kraft gesetzt wird (1. Mai 2018 – 31. März 2024). Ihre Organisation befindet sich nun im Zeitplan für PCI DSS 4.0 und muss bis März 2025 einen 4.0-konformen SAQ sowie ein Audit durch eine externe Organisation abgeschlossen haben. Die Nichteinhaltung von PCI DSS 4.0 ist keine Option, wenn Sie Umsätze über Verbraucherzahlungen verbuchen möchten.

Die PCI DSS 4.0-Spezifikation ist ein wichtiges Upgrade von 3.2.1 und Sie finden die Zusammenfassung der Änderungen hier . Version 4.0 führt zahlreiche Änderungen ein (und auch einen aktualisierten SAQ ), es gibt jedoch zwei völlig neue Bereiche, die in der Gesamtstruktur gesichert werden müssen, um die Konformität zu erreichen und aufrechtzuerhalten:

• Anwendungsprogrammierschnittstelle (API) [2.2.7; 6.2.3; 6.2.4]
• Maßgeschneiderte Software [6.X; 8.6.2; 12.8.1]

Der Einfachheit halber gehen wir nur auf einen Teil der „maßgeschneiderten Software“ etwas genauer ein. Hierbei handelt es sich um eine benutzerdefinierte Software, die von der Organisation entwickelt wurde, um Verbraucherzahlungen zu erleichtern. Maßgeschneiderte Software sieht wie folgt aus:

• Intern oder aus externen Drittquellen entwickelt
• Software, die für die Zahlungsanwendung entwickelt wurde (Serverseite der Transaktion) oder an den Webbrowser des Verbrauchers übertragen wird (Clientseite der Transaktion), um die Datenerfassung zu ermöglichen

Eine Herausforderung für viele Organisationen wird darin bestehen, die Sicherheit und PCI-DSS-Konformität maßgeschneiderter Software auf den Webbrowser des Verbrauchers auszuweiten (Anforderungen 6.4.1; 11.6.1). Um Transaktionen abzusichern, muss man heute nicht nur die Serverseite absichern, sondern auch den Webbrowser des Verbrauchers überwachen und vor der von ihm herausgebrachten „Sondersoftware“ schützen. Und auch wenn der Zahlungseintreiber für den Webbrowser des Clients maßgeschneiderte Software (z. B. JavaScript) von einem Drittanbieter bezieht, bedeutet dies nicht, dass er diese überwachen und schützen muss. Mit dem Versuch, mit dem Finger auf die Quelle zu zeigen, kommen Sie beim Prüfer nicht weiter.

Was sind also die Anforderungen an maßgeschneiderte clientseitige Software? Aus Abschnitt 6.4.1 ergibt sich folgendes:

Alle Zahlungsseitenskripte, die im Browser des Verbrauchers geladen und ausgeführt werden, werden wie folgt verwaltet:

• Es ist eine Methode implementiert, um zu bestätigen, dass jedes Skript autorisiert ist.
• Es wird eine Methode implementiert, um die Integrität jedes Skripts sicherzustellen.
• Es wird ein Inventar aller Skripte geführt, mit einer schriftlichen Begründung, warum jedes Skript erforderlich ist.

Dies bedeutet, dass die gesamte herausgegebene Software (Skripte) inventarisiert, gerechtfertigt und überwacht werden muss. Außerdem muss ein Plan zur Behebung erstellt werden, falls ein Verstoß festgestellt wird. Ist Ihr App-/IT-Sicherheitspersonal bereit, diese Anforderung zu verwalten, zu überwachen und darüber zu berichten? Haben Sie und Ihr Team mit Ihrem PCI DSS-Auditor über die Planung einer 4.0-Compliance-Prüfung gesprochen? Es ist Zeit sicherzustellen, dass Ihr Sicherheits- und PCI DSS-Compliance-Plan auf Kurs ist und Ihre Sicherheitsabläufe und – was noch wichtiger ist – die Einnahmen Ihres Unternehmens nicht stört. Denn die Sicherung der Client-Seite Ihrer Transaktionen zur Einhaltung der PCI DSS 4.0-Konformität ist viel näher, als Sie denken.