Tag Archive for: Payment transactions

PCI DSS
Janine Wolff

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!

Janine Wolff

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

New sub-requirement in all require­ments In PCI DSS version 4.0, a new sub-requirement has been included in require­ments 1 to 11, which empha­sizes the need to document, assign and under­stand roles and respon­si­bil­ities in the execution of the respective requirement x (corre­sponding sub-requirement x.1.2).
Many companies ask themselves how such an assignment of roles and respon­si­bil­ities can look like.
Does a new document have to be created?
Does this have to apply across all companies?
The PCI DSS delib­er­ately leaves the form of the documen­tation open.
The aim is to ensure that staff are aware of their respon­si­bil­ities so that the activ­ities are carried out reliably. 

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

So what can the assignment of respon­si­bil­ities look like in practice? Use of existing documen­tation In many companies, roles and respon­si­bil­ities are already included in existing guide­lines and proce­dural instructions. 

  • For example
    Does the software devel­opment guideline already include who develops the code, who carries out the code review, who carries out tests and who gives the go-ahead for the rollout as part of the process?
    And is this assignment of roles clear to everyone involved in interviews?
    Then nothing more needs to be added here in the area of software development. 

However, if such documen­tation does not yet exist, it should be created.
Whether the assignment is added to the existing document or an additional document is created is irrel­evant. Form of presen­tation The form of presen­tation is also freely selectable.
Of course, a RACI matrix or a variant thereof is ideal.
But other tables, lists or continuous text can also serve the purpose.
For large teams with similar tasks, an assignment such as “the staff is respon­sible for carrying out activity X, the team leader is respon­sible for training the staff when they are hired, when they change tasks and on an annual basis, as well as for approving the results” is often suffi­cient — for mixed teams with diverse tasks, the assignment may have to be broken down to individual persons. Link to opera­tional imple­men­tation Do not stick too closely to the PCI DSS requirement breakdown — translate how you implement compliance with security-relevant processes in your own opera­tional business.
Often, several roles are involved in the imple­men­tation of a requirement — one role may write down the rules, another role may adhere to the rules during imple­men­tation, and yet another role may review and/or approve what has been implemented.
If you write down the steps of how you implement something, it is easy to assign who is respon­sible for the respective activity. Accep­tance of respon­si­bility The assignment should, of course, not only be documented, but also known to the people involved.
Accord­ingly, a new or adapted document should be presented to the people concerned.
Do people have to sign that they are aware of their responsibility?
In another requirement of PCI DSS v4.0, requirement 12.1.3, a written acknowl­edgement of general respon­si­bility for infor­mation security is actually required.
A corre­sponding documented acknowl­edgement of the specific respon­si­bil­ities of the respective role is not mandatory in Requirement x.1.2 — but you can of course combine these two points if you wish by having not only a generic but also role-specific respon­si­bil­ities signed off.
However, this combi­nation is not mandatory. Summary So what should be the minimum at the end of the considerations? 

  • The documen­tation of roles and respon­si­bil­ities for the various tasks in the opera­tional business when securing work with payment card data, and
  • Staff who are aware of their roles, respon­si­bil­ities and tasks and can confirm this in inter­views.

In this way, compliance with the sub-require­ments x.1.2 should be feasible.

20 years SRC
Homepage Admin

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
Homepage Admin

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: Payment transactions