Der PCI Security Standards Council hat die Version 2.0 des Secure Software Standards und des dazugehörigen Programmleitfadens veröffentlicht und damit die wichtigste Überarbeitung seit der Einführung des Rahmenwerks im Jahr 2019 vorgenommen. Mit dieser Aktualisierung wird die Bewertung und Validierung von Zahlungssoftware grundlegend neu gestaltet. Es werden neue Begriffe, ein erweiterter Anwendungsbereich und gestraffte Prozesse eingeführt, die sich auf Anbieter, Prüfer und Kunden im gesamten Ökosystem des Zahlungsverkehrs auswirken.

Die Grundlage: Ein neuer Ansatz für Eignung und Umfang

Die vielleicht grundlegendste Änderung in Version 2.0 ist die vollständige Streichung des Begriffs "Zahlungssoftware" aus dem Standard. Die Zulassungskriterien konzentrieren sich nun vollständig auf das Konzept der Sensitive Assets - definiertals jedes Element des Softwareprodukts, dessen unbefugter Zugriff, Verwendung, Änderung oder Offenlegung die zahlungsbezogenen Funktionen oder Daten der Software gefährden kann.

Diese konzeptionelle Neuausrichtung wird von einem neuen obligatorischen Begleitdokument begleitet, dem Sensitive Asset Identification (SAID), das detaillierte Zusammenhänge und Beispiele für die Identifizierung sensibler Daten, Funktionen, Ressourcen und Betriebsarten liefert. Für EMVCo 3DS-bezogene Daten verweist der Standard nun auf das PCI 3DS Data Matrix Dokument.

Die praktische Auswirkung ist klar: Wenn Ihre Software sensible Daten im Sinne des Standards verarbeitet, fällt sie in den Anwendungsbereich - unabhängig davon, ob sie in die traditionellen Kategorien für Zahlungssoftware passt.

Überarbeitung der Terminologie: Die neue Sprache verstehen

Die Version 2.0 führt bedeutende terminologische Aktualisierungen ein, die von Prüfern und Anbietern verinnerlicht werden müssen:

Darüber hinaus wurde das Glossar von einem externen SSF-Dokument in Anhang A des Standards selbst verlagert, wobei definierte Begriffe nun in allen Sicherheitsanforderungen zur leichteren Erkennung markiert sind. Ein neuer Begriff, "Starke Authentifizierung", wurde eingeführt, und der Standard stützt sich jetzt auf die Grundlage von "Starke Kryptographie" anstatt auf spezifische Parameter für die effektive Schlüsselstärke.

Strukturelle Umstrukturierung: Kernanforderungen und Module

Die Norm v2.0 wurde vollständig um elf Sicherheitsziele im Kernbereich umstrukturiert, die für alle nach dem Rahmenwerk bewertete Software gelten:

1. Software-Architektur, -Zusammensetzung und -Versionierung - Einschließlich neuer Anforderungen für Stücklisten (Bill of Materials, BOM) und Wildcard-Versionierung
2. Identifizierung sensibler Güter - Schaffung der Grundlage für die nachfolgenden Anforderungen
3. Speicherung und Aufbewahrung sensibler Assets
4. Sensitive Modes of Operation - Formalisierter Kontext für Zugriffskontrolle und starke Authentifizierung
5. Schutz sensibler Assets - Einschließlich formalisierter Erkennung anomalen Verhaltens
6. Ausgabe sensibler Assets - Mit formalisierten Anforderungen an sichere Kanäle
7. Zufallszahlen - Verfeinerte Anforderungen für die Verwendung externer RNGs oder die interne Implementierung
8. Schlüsselverwaltung
9. Kryptographie - Eine einzige, umfassende Anforderung für Bereiche, die nicht anderweitig abgedeckt sind
10. Bedrohungen und Schwachstellen
11. Sichere Bereitstellung und Verwaltung - Einschließlich Anforderungen an die Implementierungsanleitung

Modul-Entwicklung: Was sich geändert hat

Modul A - Kontodatenschutz

Die Anforderungen wurden überarbeitet und konzentrieren sich nun ausschließlich auf PAN und SAD in Bezug auf PCI DSS, wobei zusätzlicher Kontext im SAID-Dokument bereitgestellt wird.

Modul B - POI-Geräte-Software

Dieses Modul wurde von "Anforderungen an die Terminalsoftware" umbenannt und erheblich gestrafft. Viele Anforderungen (B1.1, B1.2, B1.3, B3.x, B5.x) sind in den Kernanforderungen aufgegangen, und die SRED-Anforderungen wurden überarbeitet.

Modul C - Öffentlich zugängliche Software

Umbenennung von "Web-Software-Anforderungen", um den Zweck besser zu erfassen. Die Klärung des Geltungsbereichs ist von Bedeutung: Dieses Modul befasst sich mit Software, die über öffentliche Netze zugänglich ist, in denen im Grunde jeder, der über einen Netzzugang verfügt, mit der Software interagieren kann. Wichtig ist, dass Software, die nicht öffentlich zugänglich ist, dennoch nach dem Ermessen des Anbieters nach diesem Modul bewertet werden kann, da die Anforderungen dazu beitragen, das Risiko für jede Implementierung zu verringern.

Modul D - Software Development Kits (NEU)

Dieses völlig neue Modul ermöglicht die Bewertung von SDKs, einschließlich EMVCo 3DS SDKs. Der Standard besagt ausdrücklich, dass v2.0 den separaten PCI 3DS SDK-Standard ersetzen wird und den Anbietern durch den objektiveren Charakter des Secure Software Standards mehr Flexibilität bietet.

Delta Änderungen: Das neue Tier-System

Die früheren Änderungskategorien "Low Impact" und "High Impact" wurden durch eine Tier 1 und Tier 2 Delta Change Struktur ersetzt:

Delta-Änderungen der Stufe 1

• Nicht sicherheitsrelevante Änderungen, bei denen sich die Versionsnummern ändern müssen, aber keine Wildcards verwendet werden
• Vorteil für SSLC-qualifizierte Anbieter: Sicherheitsrelevante Fehlerbehebungen/Patches, selbst wenn sie sensible Daten betreffen, werden als Tier 1 eingestuft und können selbst eingereicht werden, ohne dass ein Prüfer beteiligt ist.

Tier 2 Delta Änderungen

• Einführung neuer sensibler Asset-Typen
• Änderungen, die eine Bewertung von zuvor nicht bewerteten Anforderungen erfordern
• Änderungen, die sensible Güter betreffen oder sich auf diese auswirken (mit Ausnahme der für Stufe 1 in Frage kommenden Änderungen für SSLC-Anbieter)
• Änderungen an PTS POI-Geräten
• Änderung der erforderlichen Abhängigkeiten
• Streichung bestimmter Versionen aus der Auflistung

Platzhalter: Formalisiert und wiedereingeführt

Die Versionierung von Platzhaltern wurde formell und mit klaren Regeln wieder eingeführt:

• Definition: Ein Zeichen, das in einem Versionsschema anstelle einer definierten Teilmenge möglicher Zeichen verwendet werden kann, um nicht sicherheitsrelevante Änderungen zu berücksichtigen.
• Platzhalter dürfen nur im äußersten rechten (niederwertigsten) Teil von Versionsnummern erscheinen.
• Erlaubte Platzhalterzeichen: Kleinbuchstaben {x, y, z}, Großbuchstaben {X, Y, Z} oder Sternchen (*)
• Ein einzelnes Platzhalterzeichen steht für eine einzelne Ziffernersetzung {0-9}.
• Wildcards können keine sicherheitsrelevanten Änderungen darstellen.

Diese Formalisierung ermöglicht es Anbietern, kleinere Versionen zu verwalten, ohne Änderungen an PCI SSC zu übermitteln, vorausgesetzt, die Verwendung von Platzhaltern wird während des Full Assessment validiert.

Bewertungsanforderungen: Quellcode ist verpflichtend

In der Version 2.0 wird explizit gemacht, was vorher implizit war:Die Bereitstellung von Quellcode ist obligatorisch. Im Programmleitfaden heißt es unmissverständlich:

"Vom Softwarehersteller wird erwartet, dass er den Quellcode für sein zu beurteilendes Softwareprodukt zur Verfügung stellt, sofern der Beurteiler, der die Beurteilung durchführt, dies für notwendig erachtet. Es ist nicht möglich, ein Softwareprodukt nach diesem Standard zu bewerten, ohne den entsprechenden Quellcode zur Verfügung zu stellen."

Die Testanforderungen wurden anhand von drei Methoden komplett neu geschrieben:

1. Überprüfung der Dokumentation
2. Statische Analyse
3. Dynamische Analyse

Lebenszyklus und Verwaltungsabläufe

Der 3-Jahres-Lebenszyklus der Validierung bleibt intakt:

• Jahr 1 & 2: Jährliche Bescheinigung des Anbieters erforderlich
• Jahr 3: Neubeurteilung zur Aufrechterhaltung der Liste erforderlich

Wichtige Klarstellungen in v2.0:

• Administrative Verfallsfrist: 45 Kalendertage nach Versäumnis der Bescheinigungsfrist, auf den Listen in orange dargestellt
• Verfall der Auflistung: Nach Ablauf der 45-tägigen Gnadenfrist werden Produkte zu abgelaufenen sicheren Softwareprodukten.
• Abgelaufene Produkte erfordern eine neue Bewertung, keine Neubewertung, um wieder in die Liste aufgenommen zu werden.

Benachrichtigung über Sicherheitsprobleme: Neuer dedizierter Abschnitt

Version 2.0 führt einen eigenenAbschnitt Abschnitt 8 für die Meldung von Sicherheitsmängeln ein, der die Anforderungen an die Zeitplanung für die Meldung formalisiert:

• Anforderungen an den Zeitpunkt der Benachrichtigung gemäß VRA
• Erforderliches Benachrichtigungsformat (schriftlich, mit vorausgehender E-Mail)
• Mindestangaben zur Meldung, einschließlich CVSS-Bewertung
• Reaktionsmaßnahmen des PCI SSC einschließlich eines möglichen Entzugs der Akzeptanz

Praktische Implikationen für Stakeholder

Für Software-Anbieter

• Überprüfen Sie Ihre Produkte anhand der neuen Definition von sensiblen Vermögenswerten
• Aktualisieren Sie Ihre Versionierungsmethoden, um die Vorteile von Wildcards zu nutzen.
• Bereiten Sie umfassende Stücklisten für die Bewertung vor.
• Erwägen Sie die SSLC-Qualifizierung für Tier 1 Delta Change-Vorteile
• Sicherstellung der Verfügbarkeit von Quellcode für Bewertungen

Für SSF-Bewertungsunternehmen

• Absolvieren Sie die erforderliche v2.x-Schulung, bevor Sie Assessments durchführen
• Machen Sie sich mit dem neuen SAID-Dokument vertraut
• Aktualisierung der Bewertungsmethoden für die neue Struktur der Testanforderungen
• Bereiten Sie sich auf SDK-Bewertungen unter Modul D vor.

Für Kunden

• Überprüfen Sie, ob die Anbieter Implementierungsanleitungen bereitstellen, die mit den aufgeführten Versionsnummern übereinstimmen.
• Verstehen Sie, dass erforderliche Abhängigkeiten Teil der Validierung sind - die Verwendung von nicht aufgelisteten Abhängigkeiten macht die Auflistung ungültig
• Überwachen Sie die Bescheinigungsdaten der Anbieter und die Zeitpläne für die Neubewertung.

Schlussfolgerung

PCI Secure Software Standard v2.0 stellt eine Weiterentwicklung des Rahmenwerks dar und geht von präskriptiven Zahlungssoftwarekategorien zu einem prinzipienbasierten Ansatz über, bei dem der Schutz sensibler Vermögenswerte im Mittelpunkt steht. Die Einbeziehung von SDK-Bewertungsfunktionen, die formalisierte Wildcard-Versionierung und das abgestufte Delta-Änderungssystem weisen auf ein flexibleres, nachhaltiges Validierungsprogramm hin.

Für Unternehmen, die derzeit Validierungen nach v1.x durchführen oder neue Bewertungen planen, ist es jetzt an der Zeit, sich mit qualifizierten SSF-Bewertungsunternehmen in Verbindung zu setzen, um den Übergangspfad zu verstehen und die verbesserte Flexibilität zu nutzen, die diese wichtige Revision bietet.

Der PCI Secure Software Standard v2.0 und der Program Guide v2.0 sind ab Januar 2026 gültig. Organisationen sollten die offizielle PCI SSC-Dokumentation und qualifizierte Prüfer für spezifische Compliance-Anleitungen konsultieren.