Tag Archive for: Payments

PCI DSS

Our December blog post on PCI DSS v4.0: Targeted Risk Analysis

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 oppor­tunity to take a closer look at the topic.

Targeted Risk Analysis – what is it?

PCI DSS v4.0 aims to enable more flexi­bility. 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 require­ments 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:

  • 5.2.3.1: If an organi­zation has evaluated that system compo­nents 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 deter­mined in a targeted risk analysis.
  • 5.3.2.1: If regular malware scans are used, their frequency must be deter­mined in a targeted risk analysis.
  • 7.2.5.1: Often there are not only user accounts that are used by people, but also technical user accounts that are used by systems or appli­ca­tions. Their access rights must be checked regularly. The frequency of these checks must be deter­mined in a targeted risk analysis.
  • 8.6.3: Passwords for the afore­men­tioned technical user accounts must be protected. The frequency of password changes and password complexity must be deter­mined in a targeted risk analysis.
  • 10.5.1.2.1: Payment devices (payment terminals) at the point of inter­action must be inspected regularly to detect tampering or substi­tution. The frequency and type of inspec­tions must be deter­mined in a targeted risk analysis.
  • 11.4.2.1: Security-critical logs (security events and logs from systems that come into contact with account data, have security function­ality or are otherwise critical) must be reviewed at least daily in order to detect conspicuous activ­ities promptly. The frequency of the review for all other logs must be deter­mined in a specific risk analysis.
  • 11.3.1.1: If high-risk or critical vulner­a­bil­ities are discovered during internal vulner­a­bility scans, they must be remedied. For lower-rated vulner­a­bil­ities, 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.
  • 12.10.4.1: The staff respon­sible for responding to security incidents must be trained in this. The frequency of this training must be deter­mined 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 stipu­lates 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 corre­sponding PCI DSS requirement is intended to protect.
    To determine the corre­sponding threats, it is helpful to consult the “Customized Approach Objective” of the corre­sponding 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 proba­bility of occur­rence and/or the impact of the realization of the afore­men­tioned threats.


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

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

The “Customized Approach Objective” of the overar­ching requirement 9.5.1.2 is that the tampering of devices, unautho­rized substi­tution 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 techni­cians or employees of the device provider and replace the payment device with a manip­u­lated 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 manip­ulate the payment device in such a way that its security function­ality is weakened (e.g. encryption switched off).

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

  • How easily acces­sible is the payment device to customers and third parties? Is it securely attached?
  • Is the payment device perma­nently 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 partic­u­larly worth­while target for the attacker.)
  • Has the device provider provided recom­men­da­tions in their documen­tation on how frequently the devices should be checked?

The factors then result in the analysis that deter­mines how often an activity must be carried out in order to minimize the proba­bility 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 evalu­ation, the risk analysis must be updated accordingly.

Assis­tance

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:

And as always, you are welcome to ask SRC’s PCI DSS experts for support.

Outlook

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 Question­naire A?
  • February: Customized Approach
  • March: Changes in e‑commerce: Integrity protection of payment pages

Happy New Year, and take care!

Our November blog post on PCI DSS v4.0: Roles and Responsibilities

New sub-requirement for all requirements

In PCI DSS version 4.0, a new sub-requirement has been incor­po­rated into Require­ments 1 through 11, empha­sising the necessity to document, assign, and ensure under­standing of roles and respon­si­bil­ities in executing the respective Requirement x (as stated in sub-requirement x.1.2).

This amendment raises questions for many organ­i­sa­tions. They wonder how this assignment of roles and respon­si­bil­ities should take shape. Should a new document be generated? And should it apply univer­sally throughout the entire company or solely to specialized teams?

PCI DSS delib­er­ately leaves the form of the documen­tation open. The intention of the sub-requirement is that personnel should be aware of their respon­si­bil­ities so that activ­ities are carried out reliably.

  • Almost every PCI DSS assessor has encoun­tered vulner­a­bility scans not being carried out on time every quarter because it was simply overlooked — this is where clearly assigned respon­si­bility for maintaining the quarterly rhythm helps.
  • Almost every PCI DSS assessor has encoun­tered cash desk personnel who were not aware that they had to check payment terminals on suspicion of tampering or replacement. This respon­si­bility should also be clearly stated — as well as that of the role that trains cash desk personnel to do this.

So what can the assignment of respon­si­bil­ities look like in practice?

Utilising existing documentation

Many companies already include roles and respon­si­bil­ities within their existing policies and proce­dures. 

  • For instance, your software devel­opment guide­lines may already specify who develops the code, who conducts code reviews, who performs tests, and who grants approval for rollout at different stages of the process. It’s crucial that this role allocation is trans­parent to all partic­i­pants during interviews.

However, if such documen­tation is currently absent, it should be developed. The choice of whether to integrate this assignment into existing documents or to create a new document is incon­se­quential. 

Form of Documentation

The format for documenting roles and respon­si­bil­ities is flexible. While a RACI matrix or its varia­tions are suitable, other methods such as tables, lists, or narrative texts can also serve this purpose effectively.

For sizable teams with similar tasks, a role description like “the staff is respon­sible for carrying out activity X, while the team leader is accountable for training staff during onboarding, task transi­tions, and yearly intervals, as well as for results approval” is often suffi­cient. In the case of diverse tasks within mixed teams, respon­si­bil­ities may need to be outlined for individual team members.

Connecting to Practical Imple­men­tation 

Avoid adhering too closely to the detailed require­ments of the PCI DSS. Instead, translate how you implement security-related proce­dures in your specific opera­tional business. Often, multiple roles are involved in executing a requirement: one role may define and document the rules, another role ensures compliance during opera­tional tasks, and yet another role performs a review and/or gives approval for what has been imple­mented. When you describe the steps of your imple­men­tation process, it becomes easier to identify who is respon­sible for each activity. 

Accep­tance of Responsibility

The assignment should, of course, not only be documented, but also known to the individuals concerned. Accord­ingly, a new or adapted document should be presented to the personnel that is involved.

Do employees have to sign that they are aware of their respon­si­bility? A different requirement, 12.1.3, actually requires a written acknowl­edgement of general infor­mation security respon­si­bil­ities. The documented acknowl­edgement of the specific respon­si­bil­ities of the respective role is not manda­torily required in requirement x.1.2, though. You can of course combine these two points if you wish, by having not only generic but also role-specific respon­si­bil­ities signed off. However, this combi­nation is not mandatory.

Conclusion

In conclusion, the desired outcomes at the end of these consid­er­a­tions should include:

  • Compre­hensive documen­tation of the roles and respon­si­bil­ities pertaining to various tasks in the opera­tional aspects of securing payment card data processing.
  • Ensuring that personnel are fully aware of their respective roles, respon­si­bil­ities, and tasks, and that they can confirm this awareness during inter­views. 

This approach will facil­itate compliance with sub-require­ments x.1.2.

20 years SRC

20 years SRC

20 years ago, on 27 November 2000, the founding meeting of the share­holders of SRC took place. That is a long time, but in retro­spect it does not seem to be the case for the acting persons. This perception is of course subjective, but a decisive factor will certainly be the rapid devel­opment in the field of infor­mation technology.
The complexity of digital­i­sation and the constantly growing need to create trust in new solutions is the business basis of SRC, the essential reason why SRC exists. At the same time this is also a big oblig­ation — namely to ensure that new digital solutions are really trustworthy.
SRC’s work on such things that many people experience in their daily life can be explained vividly. These are, above all, contactless payment by card and mobile phone, secure access to bank accounts by third parties, electronic patient files, secure commu­ni­cation in connection with the Galileo system and in the Bundeswehr, or even quite “mundane” things such as bottle deposit machines or tamper-proof cash registers — all topics of digiti­sation with which millions of people come into contact in one way or another every day. The devel­opment does not end there, with Open Finance, IoT and the increased use of AI methods there are still many exciting topics to be addressed.
None of these solutions has been produced or is operated by SRC itself, but we have made a decisive contri­bution to all of them: We provide confi­dence in these digital solutions — for relia­bility, security and future-proofness. We create “a good feeling” in dealing with digitalisation:
— Standards for new technologies create investment security,
— Reliable function­ality of new solutions through testing,
— Technical safety of new solutions through safety concepts and tests.
In fact, this “good feeling”, the trust, is something like the lubricant of digital­i­sation. For many people, the digiti­sation and mecha­ni­sation of everyday life means that processes are no longer manageable and the truth content of infor­mation is sometimes unclear. Trust makes it possible to reduce this complexity and often opens the door to accep­tance of the new ways of experi­encing and acting that digiti­sation aims to create.
The complexity of digital­i­sation and the constantly growing need to create trust in new solutions is the business basis of SRC, the essential reason why SRC exists. At the same time this is also a big oblig­ation — namely to ensure that new digital solutions are really trustworthy.
In the 20 years of SRC’s existence we have carried out more than 20,000 projects. Every year there have been more and also SRC has grown year by year — not only in terms of the number of employees, but especially in terms of the expansion of expertise, partly in areas that did not exist at the time of the foundation of SRC.
The current pandemic situation does not allow us to adequately celebrate our 20th anniversary, which we would have liked to do together with our customers. We are thinking about making up for this at a suitable time. But even without a party, we would be pleased if you, our customers, continue to place your trust in us.

EPayStandards Consortium

Frenchsys, Elitt and SRC found the EPay Standards Consortium

Together with the French partners Frenchsys and Elitt, SRC founds the EPayStan­dards Consortium, a cooper­ation to expand the consulting and support of inter­na­tional customers in the European payment traffic.

As a subsidiary of Cartes Bancaires, Frenchsys signif­i­cantly supports the technical and functional speci­fi­ca­tions as well as the integration in the French acquirer market.

Elitt focuses its activ­ities on the devel­opment of test case catalogs and test tools for terminals. Elitt also stands for innov­ative payment solutions.

SRC supports devel­opment and mainte­nance of the German girocard system. This includes the creation of functional and security speci­fi­ca­tions for all system compo­nents involved. Also the conception of innov­ative solutions for mobile payment is part of SRC’s service spectrum.

All three companies know the world of payment trans­ac­tions as essential carriers of European standard­ization initia­tives such as nexo, CPACE and the Berlin Group.

The EPayStan­dards consortium gives the inter­na­tional market for payment trans­ac­tions access to bundled technical and strategic consulting services. The corner­stone of the cooper­ation is laid with workshops for customers with cross-border opera­tions such as terminal manufac­turers and processing service providers.

In recent years, the European standards for payment trans­action terminals have developed further. This offers oppor­tu­nities especially for inter­na­tionally active acceptors to harmonize their terminal infra­struc­tures across borders. SRC and Frenchsys contribute detailed knowledge of these new standards and the two largest European payment trans­action markets and systems. Elitt completes the cooper­ation with its expertise in the technical prepa­ration of imple­men­ta­tions and certi­fi­ca­tions. Thus, the inter­na­tional market for payment trans­ac­tions benefits from the combi­nation of the strengths of the consortium partners.

Workshop concept eMail an: mailto:contact@epec-experts.eu

 

Tag Archive for: Payments