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” — so let’s take this as an opportunity to take a closer look at the topic.
Targeted Risk Analysis – what is it?
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 company-wide risk analyses that were required in PCI DSS v3.2.1. They look at the specific risks for a very specific use case.
In PCI DSS v4.0, targeted risk analyses appear in two places:
- Some requirements of the standard call for targeted risk analyses to determine how often a certain regular control should be carried out.
- In addition, the targeted risk analysis is part of the so-called “customized approach”, which allows you to 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 PCI DSS requirements:
- 18.104.22.168: If an organization has evaluated that system components are not commonly affected by malware and therefore do not require an anti-malware solution, then it must be checked at regular intervals to ensure that this is still the case. The frequency of these checks must be determined in a targeted risk analysis.
- 22.214.171.124: If regular malware scans are used, their frequency must be determined in a targeted risk analysis.
- 126.96.36.199: Often there are 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 aforementioned technical user accounts must be protected. The frequency of password changes and password complexity must be determined in a targeted risk analysis.
- 10.5.1.2.1: Payment devices (payment terminals) at the point of interaction must be inspected regularly to detect tampering or substitution. The frequency and type of inspections must be determined in a targeted risk analysis.
- 188.8.131.52: Security-critical logs (security events and logs from systems that come into contact with account data, have security functionality or are otherwise critical) must be reviewed at least daily in order to detect conspicuous activities promptly. The frequency of the review for all other logs must be determined in a specific risk analysis.
- 184.108.40.206: If high-risk or critical vulnerabilities are discovered during internal vulnerability scans, they 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 tampering. This mechanism must be applied at least every seven days – otherwise a lower frequency must be justified with a targeted risk analysis.
- 220.127.116.11: The staff responsible for responding to security incidents must be trained in this. The frequency of this training must be determined in a targeted risk analysis.
How to perform the targeted risk analysis
How the targeted risk analysis should be carried out is defined in requirement 12.3.1 of PCI DSS v4.0. This stipulates that the analysis must first identify at least the following points:
- The assets to be protected. Of course, those always comprise the account data itself, but other assets such as systems or passwords can also be relevant.
- 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 18.104.22.168.1 as an example.
Here, both the account data and the payment devices are assets to be protected.
The “Customized Approach Objective” of the overarching requirement 22.214.171.124 is that the tampering of devices, unauthorized substitution of devices, or the attachment of skimming devices cannot be carried out without timely detection.
Typical threat scenarios would therefore be, for example
- Attackers install skimming devices that read data input.
- 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 account 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 these threats are, for example:
- How easily accessible is the payment device to customers and third parties? Is it securely attached?
- Is the payment device permanently attended / under supervision?
- How well qualified and trained is the staff on site?
- Are the payment device and the data in it protected against tampering, and is this proven by PCI PTS validation of the device and/or PCI P2PE validation of the entire solution?
- How heavily frequented is the payment terminal? (This can have an influence on whether it is a particularly worthwhile target for the attacker.)
- Has the device provider provided recommendations in their documentation on how frequently the devices should be checked?
The factors then result in the analysis that determines 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.
At least every 12 months, each targeted risk analysis must be reviewed to check whether it is still applicable. If there have been changes in the factors or in their evaluation, the risk analysis must be updated accordingly.
As with every PCI DSS v4.0 requirement, the first thing worth looking at is the “Guidance” column to the right of the requirement in the standard itself.
In addition, the PCI SSC published three supporting documents on 28 November 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, you are welcome to ask SRC’s PCI DSS experts for support.
This is the last post 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 then
- January: Changes in e‑commerce: What’s changing in Self-Assessment Questionnaire A?
- February: Customized Approach
- March: Changes in e‑commerce: Integrity protection of payment pages
Happy New Year, and take care!