The year is drawing to a close – and so is PCI DSS v3.2.1. The PCI Security Standards Council (PCI SSC) has just published new documents on the new concept of “Targeted Risk Analysis” – we’ll take this as an opportunity to take a closer look at the topic. Targeted risk analysis – what is it? The PCI DSS v4.0 aims to enable more flexibility. One of the tools for this is the so-called “Targeted Risk Analysis”. Targeted risk analyses differ from the cross-company risk analyses that were required in PCI DSS v3.2.1. They consider the concrete risks for a very specific application. PCI DSS v4.0 contains targeted risk analyses in two places:

• Some requirements of the standard call for specific risk analyses to determine how often a particular regular measure should be carried out.
• In addition, the targeted risk analysis is part of the so-called “customized approach”, with which you can implement a requirement in your own way, deviating from the literal implementation.

We will focus on the first case here, as we will dedicate a separate blog entry to the customized approach in February.

Where is it required?

A targeted risk analysis is required for the following requirements:

• 5.2.3.1: If an organization has evaluated that system components are usually not affected by malware and therefore do not require an anti-malware solution, then it must be checked at regular intervals whether this is still the case. The frequency of these checks must be determined in a targeted risk analysis.
• 5.3.2.1: If regular malware scans are used, their frequency must be defined in a targeted risk analysis.
• 7.2.5.1: There are often not only user accounts that are used by people, but also technical user accounts that are used by systems or applications. Their access rights must be checked regularly. The frequency of these checks must be determined in a targeted risk analysis.
• 8.6.3: Passwords for the technical user accounts mentioned must be protected. The frequency of password changes and password complexity must be determined in a targeted risk analysis.
• 9.5.1.2.1: Payment devices (payment terminals) at the point of interaction must be inspected regularly in order to detect manipulation or even replacement. The frequency and type of inspections must be determined in a targeted risk analysis.
• 10.4.2.1: Security-critical logs (security events and logs from systems that come into contact with card data, have security functionality or are otherwise critical) must be reviewed at least once a day in order to detect conspicuous activities in a timely manner. The frequency of the review for all other logs must be determined in a specific risk analysis.
• 11.3.1.1: If high-risk or critical vulnerabilities are discovered during internal vulnerability scans, these must be remedied. For lower-rated vulnerabilities, a targeted risk analysis must determine how these are to be addressed.
• 11.6.1: E-commerce payment pages must be regularly checked with a mechanism for detecting changes and manipulations. This mechanism must be used at least every seven days – otherwise a lower frequency must be justified with a specific risk analysis.
• 12.10.4.1: Staff responsible for responding to security incidents shall be trained to do so. The frequency of this training must be determined in a targeted risk analysis.

How can a targeted risk analysis be carried out? How the targeted risk analysis is to be carried out is defined in requirement 12.3.1 of PCI DSS v4.0. It is specified here that the analysis must first identify at least the following points:

• The assets to be protected. Of course, the assets to be protected are always the card data itself, but they can also be assets such as systems or passwords.
• The threats against which the corresponding PCI DSS requirement is intended to protect. To determine the corresponding threats, it is helpful to consult the “Customized Approach Objective” of the corresponding or higher-level PCI DSS requirement, as this objective often already specifies the threats against which the requirement is intended to protect.
• Factors that contribute to the probability of occurrence and/or the impact of the realization of the aforementioned threats.

Let’s get specific and take requirement 9.5.1.2.1 as an example.

Here, both the card data and the payment devices are the assets to be protected.

The “Customized Approach Objective” of the superordinate requirement 9.5.1.2 is that the manipulation of devices, unauthorized replacement of devices and the installation of skimming devices cannot be carried out without prompt detection.

Typical threat scenarios would therefore be, for example

• Attackers install skimming devices that read the data entered.
• Attackers pretend to be service technicians or employees of the device provider and replace the payment device with a manipulated payment device, which then reads the card data and forwards it to the attackers.
• Attackers steal a payment device on which data could be temporarily stored in the case of offline transactions.
• Attackers manipulate the payment device in such a way that its security functionality is weakened (e.g. encryption switched off).

Factors that can have an impact on the realization of the threats in this case are, for example:

• How easily accessible is the payment device for customers and third parties? Is it securely fastened?
• Is the payment device permanently under supervision?
• How well qualified and trained is the local staff?
• Are the payment device and the data in it protected against manipulation, and is this proven by PCI PTS certification of the device and/or PCI P2PE certification of the entire solution?
• How busy is the payment machine? (This can have an influence on whether it is a particularly worthwhile target for the attacker).
• Has the device provider recommended in its documentation how often the devices should be checked?

The factors collected are then analyzed to determine how often an activity must be carried out in order to minimize the probability of the threats occurring. Factors and results of the targeted risk analysis must be documented. Every targeted risk analysis must be reviewed at least every 12 months to check whether it is still applicable. If there have been changes in the factors or in the assessment, the risk analysis must be updated accordingly. Guidance As with every PCI DSS v4.0 requirement, it is worth taking a look at the “Guidance” column to the right of the requirement in the standard. In addition, the PCI SSC published three supporting documents on November 28, 2023:

• Information Supplement PCI DSS v4.x: Targeted Risk Analysis Guidance,
• PCI DSS v4.x Sample Template: Targeted Risk Analysis for Activity, and
• PCI DSS v4.x Sample Templates to Support Customized Approach (in which, as mentioned above, targeted risk analyses are also required).

And as always, please feel free to contact the PCI DSS experts at SRC for assistance. Outlook This is the last article on PCI DSS v4.0 for this year. We will continue our monthly blog series next year – you can look forward to the following topics

• January: Changes in e-commerce: What is changing in the Self-Assessment Questionnaire A?
• February: Customized Approach
• March: Changes in e-commerce: Integrity protection of payment pages.

Have a good start to the new year and stay healthy!