Tag Archive for: PCI DSS

Information security officers for credit institutions

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

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.

PCI DSS v4.0 approaches – we support your preparation

PCI DSS is a mature standard that defines require­ments for secure processing of card data of the inter­na­tional payment brands.
Version 3 of PCI DSS, which has been valid since 2014 — with various updates -, will finally expire at the end of March 2024 and will be replaced by the new version 4.0.

We take the final steps to PCI DSS v4.0 migration with you. Please make use of our offers:

1. Monthly blog articles highlighting one PCI DSS v4.0 topic at a time

2. Free webinars summa­rizing the changes from PCI DSS v3.2.1 to v4.0 again

  • Webinar on the full PCI DSS scope (January 2023)
  • Webinar for card-present merchants with SAQ B‑IP or P2PE scope (January 2023)
  • Webinar for e‑commerce merchants with SAQ A scope (January 2023)

You find an overview about the current webinars here.

3. PCI DSS v4.0 workshops tailored to your needs, in which we specif­i­cally present and discuss the require­ments that are relevant to you.

4. A gap-analysis of your environ­ments and processes. You will receive a list of all open items for PCI DSS v4.0 compliance in your company.

5. Consul­tancy packages of your choice. You can call up quotas at any time if you have specific queries — by telephone, e‑mail, web conference, or in meetings on site.

Please feel free to contact Mrs Jana Ehler via e‑mail for further inquiries.

 

PCI DSS v4.0 release delayed

PCI DSS v4.0 release delayed

The publi­cation of a new, funda­men­tally revised version of the payment trans­action standard PCI DSS has been announced since 2019. We are eagerly awaiting the changes that the new version will bring.

After PCI DSS v4.0 had already undergone two RFC phases in 2019 and 2020, the PCI Security Standards Council has now decided to also initiate an RFC phase for supporting documents, in particular for

  • the template for the Report on Compliance (ROC),
  • the template for the Attes­tation of Compliance (AOC), and
  • the self-assessment question­naires (SAQs)

in June 2021. However, this will also delay the publi­cation of PCI DSS v4.0.

Instead of the announced release period in Q2 2021, the aimed period of final­ization is now Q4 2021. The actual release date has not yet been specified.

We must therefore be patient a little longer before we can properly plan the migration. With the shift of the publi­cation date, the planned transition periods from PCI DSS v3.2.1 to v4.0 have also been postponed. We are therefore also postponing our PCI DSS v4.0 webinars to 2022.

PCI DSS guidance for Large Organizations

PCI DSS best practices guidance for large organi­za­tions published

SRC Security Research & Consulting GmbH contributed to the most recent PCI (Payment Card Industry) Security Standards Council Special Interest Group (SIG). The resulting guidance on PCI DSS for Large Organi­za­tions is now published.

Complex organi­za­tions, corpo­ra­tions and companies often face specific challenges when imple­menting PCI DSS (Payment Card Industry Data Security Standard) require­ments: the hetero­geneity of their infra­struc­tures and processes, the constant change of corporate struc­tures, and dealing with diverse require­ments, respon­si­bil­ities and management tasks.
The new guidance on PCI DSS for Large Organi­za­tions helps large and/or complex organi­za­tions coordinate and manage their PCI DSS activ­ities across multiple environments.

  • PCI DSS guidance for Large Organi­za­tions //document.
Associate QSA

Associate QSA — quali­fying as a QSA

SRC offers mentoring programme for future Security Evaluators

The QSA accred­i­tation — the previous, unstruc­tured path to becoming a highly qualified Security Evaluator

Extensive experience is required to audit environ­ments in which payment card data is accepted and/or processed for compliance with the PCI DSS security standard. To date, there has been no standardised way of fulfilling the relevant prereq­ui­sites for admission as a PCI DSS assessor (Qualified Security Assessor, QSA) which are compre­hensive profes­sional experience, PCI DSS-specific training and testing as well as at least two other accred­i­ta­tions in the field of infor­mation security and IT auditing.

Associate QSA — the accom­panied path to QSA

With the new Associate QSA programme of the Payment Card Industry Security Standards Council (PCI SSC), an oppor­tunity has now been defined through which new talents with a basic level of profes­sional experience can advance towards QSA approval.

Associate QSA will be accom­panied by an experi­enced QSA mentor. The devel­opment and increasing audit experience of the Associate QSA are regularly reflected and documented. In this way, it is monitored and ensured that the employee has compre­hensive experience in all relevant areas until he or she obtains QSA accreditation.

SRC provides training

The SRC team is known for not consid­ering test standards as check­lists to be processed, but for deriving their appli­cation from complex environ­ments and for supporting the customer in the imple­men­tation and inter­pre­tation as practi­cally as possible. This requires compre­hensive expertise and experience in combi­nation with a constant exchange with other experts.

SRC therefore welcomes the defin­ition of a step-by-step procedure for the training and support of Associate QSA, which contributes to the devel­opment of an appro­priate quali­fi­cation. SRC has thus regis­tered as an Associate QSA company and has already approved the first employee as an Associate QSA. In this way, the quality of the audits in the constantly changing payment trans­action environ­ments is to be guaranteed also in the future.

Tag Archive for: PCI DSS