Tag Archive for: PCI

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 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.

Information security officers for credit institutions
Janine Wolff

PCI DSS v4.0 blog entry for October

PCI DSS 4.0 Evidence Guidelines

In this episode of our PCI DSS v4.0 blog, we explain assessors’ respon­si­bil­ities for providing evidence of their assessment findings, and how to prepare the provision of appro­priate evidence for PCI DSS v4.0 assessments.

Assessment process

During a PCI DSS assessment, assessors check the extent to which a company has imple­mented the PCI DSS requirements.

Typically, an assessment process includes the following steps:

  • Review of documents,
  • Review of system components/settings,
  • Review of processes,
  • Review of physical condi­tions, 
  • review of protocols/results, and
  • Inter­views with staff.

This does not change with the migration to PCI DSS v4.0.

Evidence require­ments

It usually remains hidden for the assessed company how an assessor makes notes and files evidence. We provide insight into the corre­sponding changes with PCI DSS v4.0.

With the new reporting template for PCI DSS v4.0 as well as with an update of the PCI DSS Program Guide for QSAs, the PCI SSC has now clarified that they require the assessor to file a corre­sponding evidence for each assessment step. The PCI SSC checks whether the assessor companies meet this by taking samples.

For documents, this is easy: the respective document itself is the required evidence. Regarding protocols/results, it is similar – here you just have to make sure that it is clear which system or process you are talking about.

 If you send a screenshot or file to an assessor as evidence, please make sure to include the infor­mation which system component and/or process it is about. When reviewing system components/settings, the assessor must take dedicated notes on the system and setting in question.

When reviewing processes or physical condi­tions, the respective condition must be described in detail and it must be shown what conclu­sions the assessor draws from the obser­vation. Similarly, in an interview, the assessor is expected to roughly write down the questions and answers.

Please give the assessor enough time to take notes during the assessment. In many cases, it can shorten the paperwork if the assessor is provided with copies or screen­shots or is allowed to take photos.

The PCI DSS v4.0 lists about 250 sub-items for the 12 main require­ments — the assessor will need a corre­spond­ingly large amount of evidence.

Retention require­ments

The PCI DSS Program Guide requires that all of the above evidence must be securely retained by the assessor company for at least three years and made available to the PCI SSC and associated companies upon request.

For reasons of privacy or confi­den­tiality, companies sometimes do not allow the assessor to take and file certain evidence. In this case, the PCI SSC stipu­lates that the evidence may be filed with the assessed company instead. The require­ments for retention period and avail­ability are the same in this case.

Since the oblig­a­tions to provide evidence have become greater with PCI DSS v4.0, this case is expected to occur more frequently in the future.

 If you expect that not all evidence may be passed on to the assessor, the best way to prepare yourself as an assessed company is by

  • preparing an audit-proof storage of the evidence for at least three years,
  • keeping a list of documents and evidence not handed over during the assessment,
  • preparing a written confir­mation for the assessor, in which you 
    • name the place of storage,
    • name the contact person whom the PCI SSC can contact if it wishes to inspect evidence, and
    • confirm audit-proof storage until a specific date at least three years in the future.

Dealing with deviations

How about evidence if the assessment did not immedi­ately demon­strate compliance with all require­ments, but devia­tions were found?

Planned devia­tions

In the simplest case is when you, as the assessed company, have already recog­nised in advance that you cannot fulfil a requirement or do not want to fulfil it in the specified way. In this case, you have already prepared documen­tation of a compen­sating control or a customised approach for the assessment. A PCI DSS expert can also help you with this — but it must not be the same individual who then assesses the implementation.

We will comment in detail on the Customised Approach in a later episode of our PCI DSS v4.0 blog.

In both cases, the assessor will review the evidence of your company’s Compen­sating Control or Customised Approach, ask questions if necessary, and then derive and implement appro­priate testing methods. The oblig­a­tions to collect evidence result from the respective assessment method.

Unplanned devia­tions — “INFI”

If unplanned devia­tions from PCI DSS require­ments occur during an assessment period, they must be remedied and the remedi­ation verified by the assessor. This was already the case in PCI DSS v3.2.1.

Additionally, PCI DSS v4.0 additionally explicitly requires that the cause for the occur­rence of the deviation is identified and that processes are imple­mented to prevent a recur­rence of such a deviation. Only if this is the case, the assessor can still consider the requirement as in place.

All devia­tions, their causes, corrective and preventive controls must be documented in the new “Items Noted For Improvement” (INFI) document for any PCI DSS v4.0 assessment.

The assessor provides the INFI document to the assessed company at the end of the assessment and both parties sign it. The INFI document proves that the assessed company has success­fully managed the devia­tions. The document can be used inter­nally within the assessed company — e.g. in compliance and risk depart­ments — and can also be shared with third parties if desired. There is no oblig­ation to present the INFI document anywhere, nor is it refer­enced in the Attes­tation of Compliance (A.O.C).

 Partic­u­larly for processes that have to be repeated regularly, it happens from time to time that one instance is delayed, e.g. within the imple­men­tation of 

  • security awareness trainings,
  • inspection of payment devices,
  • vulner­a­bility scans, or
  • instal­lation of patches.

It is best to consider in advance how you can design your processes in such a way that you adhere to the prescribed time periods and notice delays immedi­ately.

For further questions feel free to contact Mrs Jana Ehlers.

PCI DSS v4.0
Janine Wolff

PCI DSS v4.0 blog entry for September

Timeline for PCI DSS v4.0 migration – What are the next steps?

With March 31, 2024, the end of PCI DSS v3.2.1 is approaching. All merchants accepting payments with cards of the inter­na­tional payment brands Visa, Mastercard, American Express, Discover, JCB, or UnionPay, and all service providers supporting them, should be prepared for PCI DSS v4.0.

But what should be done in particular, and when?

Gap analysis

The first step should be a gap analysis. Anyone who has not yet checked which new require­ments come up to them with PCI DSS v4.0 should do so as soon as possible! The reasons are obvious:

  • Imple­menting new require­ments will require time and resources.
  • PCI DSS profes­sionals who can advise on imple­men­tation are already well booked.

During the gap analysis, the new require­ments must be read, under­stood, and aligned with the existing landscape of controls. To under­stand the require­ments, it is extremely helpful to read not only the requirement itself, but also the extensive guidance that the PCI SSC has provided alongside each requirement within the standard:

  • The “Guidance” column (to the right of the requirement),
  • the objective being pursued by the requirement (below the requirement),
  • and, if available, the applic­a­bility note (below the requirement).

The intro­ductory chapters of PCI DSS v4.0 and the glossary in Appendix G can also support in under­standing termi­nology and applicability.

If you work with a PCI DSS expert at present, feel free to draw on their expertise and experience within this step already.

Priori­ti­sation

When all open items have been identified, timeframes and respon­si­bil­ities should be assigned. When assigning timeframes, the following should be considered:

  1. How long will the imple­men­tation take?

The imple­men­tation of new technical solutions often takes a long time due to internal depen­dencies. Often this comes together with low human resources. Issues that are expected to take a long time to implement need to be addressed earlier than those where a quick completion is expected.

  1. Are targeted risk analyses required?

In v4.0, for many regular tasks the frequency of perfor­mance is no longer prede­fined, but is to be deter­mined by a targeted risk analysis. The imple­men­tation of such targeted risk analyses must be coordi­nated inter­nally and hence requires time.

  1. Are there periods that are partic­u­larly good or bad for implementation?
    g. for policy changes, it can make sense to consider document review cycles. For technical changes, it makes sense to consider any freeze periods or release periods that have already been planned.
  2. Is the PCI DSS v4.0 deadline for this requirement 2024 or 2025?

For many funda­men­tally new require­ments in PCI DSS v4.0, the applic­a­bility notes state that the requirement is considered best practice until 31 March 2025, after which it is mandatory.

Require­ments without this note must be imple­mented by 31 March 2024 and might therefore require a higher prioritisation

Decisions

For some new require­ments, there are different ways to implement them. Examples are:

  • Requirement 3.4.2 calls for preventing copying/moving of PAN when accessing remotely (except for personnel with appro­priate business need). There can be several ways to implement this, too — e.g. via a setting in RDP when using the remote connection, or by preventing highlight­ing/­copy­ing/­mouse-right-clicking on PAN displays on according web pages.
  • Requirement 8.4.2 requires multi-factor authen­ti­cation (MFA) when accessing the Cardholder Data Environment (CDE).Depending on how the access towards the CDE takes place, it may make sense to enforce MFA at network level, at system level, or at appli­cation level. This decision must be well weighed with the various parties involved. Several parties may even have to work together on the solution.

Weigh up the impact of different solutions at an early stage!

Tracking and Assessing

Once you have priori­tised your tasks and decided on imple­men­tation paths: please do not sit back! The person or team respon­sible for maintaining PCI DSS compliance should stay in contact with the teams respon­sible for the implementation.

  • Are there any enquiries/comprehension issues?
  • Do any problems with the imple­men­tation arise?
  • Is the agreed target date at risk?

As soon as a new solution has been imple­mented, it should be checked whether it meets the corre­sponding PCI DSS requirement. External PCI DSS experts can also support with small interim pre-assess­ments in order to be on the safe side for the next official annual assessment.

Continuous Process

Once a requirement is met, there is no guarantee that it will remain so. Card data usage, technologies and attack vectors change. Already today, PCI DSS v3.2.1 comprises regular tasks for maintaining PCI DSS compliance. With PCI DSS v4.0, this is becoming even more of an ongoing process.

Therefore, get into the habit of putting your controls to the test repeatedly, and of adhering to the timeframes for recurring activ­ities (now precisely defined in chapter 7 of the PCI DSS). This will also make it easier for you to comply with new corre­sponding require­ments, such as e.g.

  • 2.4 / 7.2.5.1 Review of user accounts and assigned access rights,
  • 3 Review of risk assess­ments and review of the appro­pri­ateness and security of crypto­graphic algorithms, hardware and software technologies used,
  • 5 Validate the PCI DSS appli­cation scope; and
  • 6.2 Review of the security awareness programme.

Above All: Start!

This is the most important step. If you haven’t started yet, today is the best day to do so. Assemble a team and schedule time.

Should you need any assis­tance do not hesitate to contact Jana Ehlers via email.

Homepage Admin

SRC goes GEAR (Global Executive Assessor Roundtable)!

PCI SSC and SRC

The Payment Card Industry Security Standards Council (PCI SSC) is a global forum that develops and promotes the use of infor­mation security standards for secure payments. It is respon­sible for 15 globally recog­nized and widely used standards for securing electronic payment processes — from payment card production and issuance to payment at the point of interest or in web & app, to the processing of payments in the background.

SRC has been assessing the use of those infor­mation security standards since PCI SSC was founded by means of corre­sponding assess­ments and product evalu­a­tions. The PCI SSC attaches great impor­tance to the exchange between different stake­holders and uses various committees and activ­ities for this purpose. SRC has so far partic­i­pated in Special Interest Groups and Task Forces as well as in Community Meetings and Request for Comment phases.

Global Executive Assessor Roundtable

The PCI SSC has been giving experi­enced assessor companies the oppor­tunity to advise its senior management since 2018 through the Global Executive Assessor Round­table (GEAR). We are excited that our company has been selected this year to be part of the inter­faces between leadership of the PCI SSC itself and leadership of the assessment companies by this respon­sible membership. This will enable us to contribute our years of experience in a direct way. The nomination is valid for the next two years and gives us the oppor­tunity to play an influ­ential role in the further devel­opment of speci­fi­ca­tions for assessment proce­dures, new training programs and quali­fi­cation require­ments for future assessors. Other GEAR respon­si­bil­ities include finding ways to promote assessors’ engagement in emerging and new markets, and optimizing assessors’ skills to add value for payments companies

We are proud to be included in this circle and see it as a recog­nition of our past perfor­mance and relevance in the payments security market. At the same time, we are aware of our respon­si­bility to act as a repre­sen­tative for a large community of assessment companies and take this as an additional incentive for the future.

Link to GEAR: https://www.pcisecuritystandards.org/about_us/global_executive_assessor_roundtable/

Aspects of Common Criteria Certifications
Janine Wolff

Aspects of Common Criteria Certi­fi­ca­tions — Guest lecture at the Vienna University of Technology

Aspects of Common Criteria Certi­fi­ca­tions — this is the topic of the lecture that the experts of the SRC evalu­ation body for Common Criteria will address at the Vienna University of Technology. The lecture will take place on 10 May 2019 as part of the lecture IT Security in Large IT Infra­struc­tures at the Institute of Infor­mation Systems Engineering.

Common Criteria in science

With the help of Common Criteria for Infor­mation Technology Security Evalu­ation (CC), IT products can be evaluated regarding their security according to general criteria. As an inter­na­tionally recog­nised standard, Common Criteria is of interest to the scien­tific world. Initially, an evalu­ation is carried out by an evalu­ation body accredited by the German Federal Office for Infor­mation Security (BSI). SRC is accredited as such a CC evalu­ation body. The BSI then carries out the certification.

Guest lecture for students

The SRC experts will discuss the Aspects of Common Criteria Certi­fi­ca­tions at first hand. The lecture informs the students about the basic approach for product certi­fi­ca­tions according to Common Criteria. Infra­struc­tures in the European Union that rely on Common Criteria certi­fi­cation will be highlighted. The formal side including the respon­sible certi­fi­cation and recog­nition bodies will also be considered. The comparison of Common Criteria with other concepts concludes the lecture. Certi­fi­ca­tions according to technical guide­lines of the BSI, ISO27001 or the criteria of the Payment Card Industry (PCI) will be considered.

Tag Archive for: PCI