DE EN
dark

PCI-DSS 4.0 endlich am Start

Avatar

Obwohl die aktuelle Version (3.2.1) noch bis März 2024 gültig ist, sollten sich Organisationen, die dem PCI DSS unterliegen, so schnell wie möglich auf die Aktualisierung vorbereiten. Was bedeutet das nun?

Die wichtigste Änderung des PCI DSS v4.0 [2] ist die Einführung des kundenspezifischen Ansatzes. Bisher war der Standard sehr vorschreibend und bot wenig Flexibilität, wie Unternehmen die Anforderungen erfüllen können.

Dies ändert sich nun mit der Version 4.0 [2]. Ein Unternehmen kann nun anstelle der definierten Anforderungen seine eigenen Kontrollen einsetzen, um das Ziel jeder PCI DSS-Anforderung zu erreichen. Organisationen sollten dies jedoch nicht als “Freifahrtsschein” betrachten.

Es gibt strenge Regeln für die Verwendung des kundenspezifischen Ansatzes. Für jeden angepassten Ansatz, den die Einrichtung anwendet, muss sie:

 – Die Kontrolle definieren.

 – Erklären, wie sie funktioniert und aufrechterhalten wird.

 – Beschreiben, wie sie das Ziel der ursprünglichen PCI DSS-Anforderung erfüllt.

Die Organisation muss beschreiben, wie sie getestet hat, dass die Kontrolle das Ziel sowie die Ergebnisse des Testens erfüllt. Außerdem muss die Organisation für jede auf diese Weise behandelte Anforderung eine Risikobewertung durchführen.

Bei der Konformitätsbewertung wird ein Sicherheitsbegutachter, der Qualified Security Assessor (QSA) im deutschen qualifizierter Sicherheitsgutachter, diese Informationen prüfen und ein eigenes Testverfahren für die Anforderung entwickeln.

Es besteht eindeutig das Potenzial für viel Arbeit. Zusätzlich könnte dies zu Meinungsverschiedenheiten zwischen der bewerteten Einrichtung und dem QSA darüber führen, ob die implementierten Kontrollen die Ziele des PCI DSS erfüllen.

Die Scoping-Anforderungen werden verstärkt

Eine weitere wichtige Änderung betrifft die Anforderungen des PCI DSS an das Scoping. Es lag schon immer in der Verantwortung des bewerteten Unternehmens, den Umfang der Karteninhaberdaten-Umgebung (CDE, engl.: Cardholder Data Environment) zu definieren und zu dokumentieren sowie in der Verantwortung des QSA, dies zu validieren.

Nichtsdestotrotz wurde diese Anforderung in dem Berichts-Abschnitt zu Beginn des Standards versteckt. In der Praxis verließen sich viele Organisationen darauf, dass ihr QSA den Umfang bei der Durchführung der Bewertung sowohl definiert als auch validiert.

Dies ist nun nicht mehr möglich. Es ist nun eine spezifische Anforderung (12.5.2), dass die Organisation den Umfang der CDE, einschließlich der Identifizierung der Datenflüsse und aller Segmentierungskontrollen, definiert und dokumentiert.

Dieser Prozess muss jährlich und nach jeder wesentlichen Änderung der Umgebung durchgeführt werden. In Zukunft wird die erste Frage, die ein QSA stellt, wahrscheinlich lauten:

“Haben Sie den Umfang Ihres CDE definiert und dokumentiert?”

PCI DSS v4.0 führt auch Änderungen am Risikobewertungsprozess ein. Die betroffenen Unternehmen sind nicht mehr verpflichtet, eine organisationsweite Risikobewertung durchzuführen, aber es gibt mehrere neue Regeln für gezielte Bewertungen. Dazu gehören Risikobewertungen in Bezug auf jede festgestellte Schwachstelle und die Festlegung der Häufigkeit, mit der die Organisation diese durchführt:

 – Bewertungen von Komponenten, die nicht durch Malware gefährdet sind.

 – Malware-Scans.

 – Überprüfungen von POI-Geräten (Interaktionspunkt, engl.: Point Of Interaction).

 – Log-Überprüfungen für “andere” Systemkomponenten.

 – Schulungen zur Reaktion auf Vorfälle.

 – Obligatorische Änderung von Passwörtern für Anwendungs- und Systemzugangskonten.

Diese Änderungen sind sinnvoll, da es unwahrscheinlich war, dass der allgemeine Risikobewertungsprozess einer Organisation Angelegenheiten auf dieser Granularitätsebene aufgreifen würde.

Andere Änderungen des Standards spiegeln modernere Informationsverarbeitungsumgebungen wider. So wird in der Version 4.0 beispielsweise anerkannt, dass Netzkontrollen, insbesondere in Cloud-Umgebungen, nicht immer über Firewalls und Router erfolgen.

Darüber hinaus heben die neuen Regeln die Bedeutung starker Passwörter hervor, indem sie vorschreiben, dass die Anmeldedaten der Mitarbeiter mindestens 12 Zeichen lang sein müssen (oder 8, falls die Systeme des Unternehmens keine so langen Passwörter zulassen).

Hinweis: Der Autor hält eher 16 Zeichen für mindestens als angezeigt, und bei priviligierten Anmeldungen mindestens 32 Zeichen

PCI DSS v4.0 bietet Organisationen auch die Möglichkeit, den Zugang zu Ressourcen automatisch zu bestimmen, indem der Sicherheitsstatus der Konten dynamisch analysiert wird, anstatt die Passwörter alle 90 Tage zu ändern.

Neue Anforderungen

Neben der Änderung bestehender Anforderungen führt PCI DSS v4.0 mehrere neue Regeln ein. Dazu gehört der verpflichtende Einsatz von:

 – Automatisierte Mechanismen zum Schutz vor Phishing.

 – Firewalls für Web-Anwendungen.

 – Automatisierte Mechanismen zur Durchführung von Protokollprüfungen.

Außerdem gibt es zusätzliche Anforderungen, die sich speziell auf Konten der Anwendungs- und Systemebene beziehen.

Schließlich gibt es zahlreiche Änderungen im Wortlaut und in der Nummerierung der Anforderungen, auch wenn die eigentlichen Anforderungen weitgehend auf dem Stand von Version 3.2.1 geblieben sind.

Wenn Organisationen Richtlinien und Verfahren ausgearbeitet haben, die sich auf bestimmte Anforderungen beziehen, erfordert dies allein schon eine umfassende Überprüfung und Aktualisierung dieser Richtlinien und Verfahren.

Sie sollten nicht vergessen, wie viel Zeit die Umsetzung dieser neuen Anforderungen und die Aktualisierung Ihrer Dokumentation in Anspruch nehmen wird. Eine Vorlaufzeit von zwei Jahren mag viel erscheinen, aber es ist ratsam, frühzeitig damit zu beginnen, um das Ausmaß und die Auswirkungen der Änderungen abzuschätzen.

Referenz

[1] https://blog.pcisecuritystandards.org/pci-dss-v4-0-resource-hub

[2] https://www.pcisecuritystandards.org/document_library?category=pcidss

Pierre Gronau ist seit über 25 Jahren für namhafte Unternehmen als Senior IT-Berater mit umfangreicher Projekterfahrung tätig. Zu seinen Kompetenzfeldern gehören Server-Virtualisierungen, IT-Sicherheit, moderne Cloud- und Automationslösungen sowie Informationsschutz.

Total
0
Shares
Previous Post

Modularization: Foundation of Microservices and Monoliths | Eberhard Wolff (EN)

Next Post

Die NIS-Richtlinie

Related Posts