Das Jahr neigt sich dem Ende zu – und der PCI DSS v3.2.1 auch.

Das PCI Security Standards Council (PCI SSC) hat gerade neue Dokumente zum neuen Konzept „Targeted Risk Analysis“ (gezielten Risiko­analyse) veröf­fent­licht – das nehmen wir doch gleich zum Anlass, das Thema mal etwas genauer zu betrachten.

Targeted Risk Analysis – was ist das?

Der PCI DSS v4.0 zielt darauf ab, mehr Flexi­bi­lität zu ermög­lichen. Eines der Werkzeuge hierfür ist die sogenannte „Targeted Risk Analysis“ (gezielten Risikoanalyse).

Gezielte Risiko­ana­lysen unter­scheiden sich von den firmen­über­grei­fenden Risiko­ana­lysen, die in PCI DSS v3.2.1 gefordert waren. Sie betrachten die konkreten Risiken für einen ganz spezi­ellen Anwendungsfall.

Im PCI DSS v4.0 kommen gezielte Risiko­ana­lysen an zwei Stellen vor:

• Einige Anfor­de­rungen des Standards verlangen gezielte Risiko­ana­lysen, um festzu­legen, wie häufig eine bestimmte regel­mäßige Maßnahme durch­ge­führt werden sollte.
• Außerdem ist die gezielte Risiko­analyse Teil des sogenannten „Custo­mized Approach“, mit dem man eine Anfor­derung auf eigene Weise, abwei­chend von der wortwört­lichen Umsetzung, umsetzen kann.

Wir werden uns hier auf den ersten Fall konzen­trieren, da wir dem Custo­mized Approach im Februar noch einen eigenen Blog-Eintrag widmen werden.

Wo wird sie gefordert?

Eine gezielte Risiko­analyse wird bei den folgenden Anfor­de­rungen gefordert:

• 5.2.3.1: Wenn eine Organi­sation für System­kom­po­nenten evaluiert hat, dass diese üblicher­weise nicht von Malware betroffen sind und daher keine Anti-Malware-Lösung benötigen, dann muss in regel­mä­ßigen Abständen überprüft werden, ob dies immer noch so ist. Die Häufigkeit dieser Überprü­fungen muss in einer gezielten Risiko­analyse festgelegt werden.
• 5.3.2.1: Wenn regel­mäßige Malware-Scans verwendet werden, muss deren Häufigkeit in einer gezielten Risiko­analyse festgelegt werden.
• 7.2.5.1: Häufig gibt es nicht nur Nutzer­konten, die von Personen genutzt werden, sondern auch technische Nutzer­konten, die von Systemen oder Anwen­dungen genutzt werden. Deren Zugriffs­rechte müssen regel­mäßig überprüft werden. Die Häufigkeit dieser Überprü­fungen muss in einer gezielten Risiko­analyse festgelegt werden.
• 8.6.3: Passwörter für die genannten techni­schen Nutzer­konten müssen geschützt werden. Die Häufigkeit der Passwort­wechsel und die Passwort-Komple­xität müssen in einer gezielten Risiko­analyse festgelegt werden.
• 9.5.1.2.1: Zahlgeräte (Zahlter­minals) am Point of Inter­action müssen regel­mäßig inspi­ziert werden, um Manipu­la­tionen oder gar ihren Austausch zu erkennen. Die Häufigkeit und Art der Inspek­tionen müssen in einer gezielten Risiko­analyse festgelegt werden.
• 10.4.2.1: Sicher­heits­kri­tische Logs (Security Events sowie Logs von Systemen, die mit Karten­daten in Berührung kommen, Sicher­heits­funk­tio­na­lität haben oder ander­weitig kritisch sind) müssen mindestens einmal am Tag einem Review unter­zogen werden, um auffällige Aktivi­täten zeitnah zu entdecken. Die Häufigkeit des Reviews für alle anderen Logs muss in einer gezielten Risiko­analyse festgelegt werden.
• 11.3.1.1: Werden bei internen Schwach­stel­len­scans hochris­kante oder kritische Schwach­stellen entdeckt, müssen diese behoben werden. Für niedriger einge­stufte Schwach­stellen muss eine gezielte Risiko­analyse festlegen, wie diese zu adres­sieren sind.
• 11.6.1: E‑Com­merce-Zahlseiten müssen regel­mäßig mit einem Mecha­nismus zur Erkennung von Änderungen und Manipu­la­tionen überprüft werden. Dieser Mecha­nismus muss mindestens alle sieben Tage angewendet werden – andern­falls muss eine geringere Häufigkeit mit einer gezielten Risiko­analyse begründet werden.
• 12.10.4.1: Das Personal, das für die Reaktion auf Sicher­heits­vor­fälle zuständig ist, muss darin geschult werden. Die Häufigkeit dieser Schulungen muss in einer gezielten Risiko­analyse festgelegt werden.

Wie kann man die gezielte Risiko­analyse durchführen?

Wie die gezielte Risiko­analyse durch­ge­führt werden soll, ist in Anfor­derung 12.3.1 des PCI DSS v4.0 definiert. Hier ist festgelegt, dass die Analyse zunächst mindestens folgende Punkte identi­fi­zieren muss:

• Die zu schüt­zenden Güter (Assets). Zu schüt­zende Assets sind natürlich immer die Karten­daten selbst, aber zusätzlich können es auch Assets wie Systeme oder Passwörter sein.
• Die Bedro­hungen, gegen die die entspre­chende PCI DSS-Anfor­derung schützen soll.
  Zur Bestimmung der entspre­chenden Bedro­hungen ist es hilfreich, das „Custo­mized Approach Objective“ der entspre­chenden bzw. der überge­ord­neten PCI DSS-Anfor­derung zu Rate zu ziehen, da in dieser Zielsetzung häufig bereits Bedro­hungen benannt sind, gegen die die Anfor­derung schützen soll.
• Faktoren, die die Eintritts­wahr­schein­lichkeit und/oder die Auswir­kungen der Reali­sierung der genannten Bedro­hungen beitragen.

Werden wir konkret und nehmen als Beispiel die Anfor­derung 9.5.1.2.1.

Hier sind sowohl die Karten­daten als auch die Zahlgeräte die zu schüt­zenden Assets.

Das „Custo­mized Approach Objective“ der überge­ord­neten Anfor­derung 9.5.1.2 ist, dass die Manipu­lation der Geräte, unauto­ri­sierter Austausch der Geräte, sowie das Anbringen von Skimming-Devices nicht ohne zeitnahe Entde­ckung durch­ge­führt werden können.

Typische Bedro­hungs­sze­narien wären also bspw.:

• Angreifer bringen Skimming-Devices an, welche Eingaben mitlesen.
• Angreifer geben sich als Service-Techniker oder Mitar­beiter des Geräte-Providers aus und tauschen das Zahlgerät durch ein manipu­liertes Zahlgerät aus, welches die Karten­daten anschließend mitliest und an Angrei­fende weiterleitet.
• Angreifer stehlen ein Zahlgerät, auf dem im Fall von offline Trans­ak­tionen Daten temporär gespei­chert sein könnten.
• Angreifer manipu­lieren das Zahlgerät so, dass dessen Sicher­heits­funk­tio­na­lität geschwächt wird (bspw. Verschlüs­selung ausgeschaltet).

Faktoren, die sich auf die Reali­sierung der Bedro­hungen auswirken können, sind in dem Fall zum Beispiel:

• Wie leicht ist das Zahlgerät für Kunden und Dritte erreichbar? Ist es sicher befestigt?
• Ist das Zahlgerät dauerhaft unter Beaufsichtigung?
• Wie gut ist das Personal vor Ort quali­fi­ziert und geschult?
• Sind das Zahlgerät und die Daten darin vor Manipu­la­tionen geschützt, und ist dies durch eine PCI PTS-Zerti­fi­zierung des Geräts und/oder eine PCI P2PE-Zerti­fi­zierung der ganzen Lösung nachgewiesen?
• Wie stark frequen­tiert ist das Zahlgerät? (Das kann einen Einfluss darauf haben, ob es ein besonders lohnens­wertes Ziel für den Angreifer ist.)
• Hat der Geräte-Provider in seiner Dokumen­tation Empfeh­lungen gegeben, wie häufig die Geräte überprüft werden sollen?

Aus den gesam­melten Faktoren resul­tiert dann schließlich die Analyse, die bestimmt, wie häufig eine Tätigkeit ausge­führt werden muss, um die Wahrschein­lichkeit, dass die Bedro­hungen eintreten, zu minimieren.

Faktoren und Ergeb­nisse der gezielten Risiko­analyse müssen dokumen­tiert werden.

Mindestens alle 12 Monate muss jede gezielte Risiko­analyse einem Review unter­zogen werden, um zu überprüfen, ob sie noch zutrifft. Hat es Verän­de­rungen in den Faktoren oder in der Einschätzung gegeben, muss die Risiko­analyse entspre­chend aktua­li­siert werden.

Hilfe­stel­lungen

Wie bei jeder Anfor­derung des PCI DSS v4.0 lohnt sich als erstes ein Blick in die „Guidance“-Spalte, die im Standard rechts von der Anfor­derung steht.

Zusätzlich hat das PCI SSC am 28. November 2023 drei unter­stüt­zende Dokumente veröffentlicht:

• Infor­mation Supplement PCI DSS v4.x: Targeted Risk Analysis Guidance,
• PCI DSS v4.x Sample Template: Targeted Risk Analysis for Activity, und
• PCI DSS v4.x Sample Templates to Support Custo­mized Approach (worin, wie oben benannt, auch gezielte Risiko­ana­lysen gefordert sind).

Und wie immer können Sie auch gerne die PCI DSS-Experten von SRC um Unter­stützung bitten.

Ausblick

Dies ist der letzte Beitrag zu PCI DSS v4.0 für dieses Jahr. Wir setzen unsere monat­liche Blog-Reihe nächstes Jahr fort – freuen Sie sich dann auf die Themen

• Januar: Änderungen im E‑Commerce: Was ändert sich beim Self-Assessment Questi­on­naire A?
• Februar: Custo­mized Approach
• März: Änderungen im E‑Commerce: Integri­täts­schutz von Zahlseiten.

Kommen Sie gut ins neue Jahr und bleiben Sie gesund!