Janine Wolff

SRC joins PCI SSC Global Executive Assessor Round­table (GEAR)

SRC is again one of 33 organi­za­tions to join the PCI Security Standards Council’s Global Executive Assessor Round­table (GEAR) in its efforts to secure payment data globally. As strategic partners, GEAR members bring industry, geographical and technical insight to PCI SSC plans and projects on behalf of the assessor community. The PCI SSC Global Executive Assessor Round­table serves as a direct channel for commu­ni­cation between senior leadership of leading payment security assessors and PCI SSC senior leadership

Please find the official GEAR Announcement 2024 2026 Press Release here.

“We need voices from across the assessor community to help ensure we are providing the best standards and programs to support the industry in protecting against today’s modern cyber­criminal. We’re pleased to have SRC on the PCI SSC Global Executive Round­table to provide critical insights and help us build on the great efforts that are already being done to increase payment security globally.”
(PCI SSC Executive Director Gina Gobeyn)

The PCI Security Standards Council (PCI SSC) leads a global, cross-industry effort to increase payment security by providing industry-driven, flexible, and effective data security standards and programs that help businesses detect, mitigate, and prevent cyber­at­tacks and breaches. Connect with the PCI SSC on LinkedIn.

Janine Wolff

Secure operation of healthcare appli­ca­tions in the cloud: a review of DMEA 2024

DMEA 2024 was once again an impressive platform for innovation and exchange in the healthcare sector. One of our highlights was the panel discussion on the secure operation of healthcare appli­ca­tions in the cloud, in which our colleague Dr. Jens Putzka, together with experts such as Tim Ohlendorf from gematik GmbH and Jonatan Reiners from kreuzw­erker, provided in-depth insights into current challenges and solutions. 

Focus on challenges and solutions

During the discussion, various challenges associated with the operation of healthcare appli­ca­tions in the cloud were addressed. Data protection, data security and compliance with regula­tions are just some of the critical issues that need to be considered when devel­oping and imple­menting such applications. 

Daten­schutz und Datensicherheit

A central point of the discussion was data protection. Health data is partic­u­larly sensitive and must be handled with the utmost care. The experts empha­sized the need for strict security protocols and encryption methods to ensure that data is protected during trans­mission and storage. 

Compliance with regulations

Compliance with legal require­ments and regula­tions, such as the General Data Protection Regulation (GDPR), is another challenge. Tim Ohlendorf from gematik GmbH explained gematik’s role in ensuring that healthcare appli­ca­tions comply with these regula­tions and how they help to set standards for the industry. 

Innov­ative solutions

One of the most exciting innova­tions presented is the concept of confi­dential computing. This technology makes it possible to process data in a secure, isolated environment, signif­i­cantly improving security and confi­den­tiality even in cloud environments. 

Confi­dential Computing

Jonatan Reiners from kreuzw­erker explained how confi­dential computing works and how it can be used to protect sensitive healthcare data. By using secure hardware and special encryption techniques, data can be shielded during processing, which minimizes the risk of data leaks and unautho­rized access. 

Conclusion and thank you

The panel discussion at DMEA 2024 clearly showed that the secure operation of healthcare appli­ca­tions in the cloud poses both challenges and innov­ative solutions. Die Experten­runde bot wertvolle Einblicke und praktische Ansätze, die die Zukunft der digitalen Gesundheit sicherer und effizienter gestalten können. A big thank you goes to gematik for the invitation and the excellent organi­zation of the event. For all those who were unable to be in Berlin, the full video of the discussion is available online.  

Janine Wolff

SRC Security Research & Consulting GmbH: Gener­ation change at the top

After almost 25 years of successful management of the company by Gerd Cimiotti, the founda­tions are now being laid for a gener­a­tional change in the management of SRC — and thus for the next 25 years. With effect from August 1, 2024, Markus Schierack will be appointed to the management board of SRC Security Research & Consulting GmbH, Bonn.

As Managing Director of the payment trans­action institute VÖB-ZVD Processing GmbH (“Pagateq”), he has been respon­sible for business devel­opment, payment trans­ac­tions, finance and regulatory affairs, among other things. Markus Schierack brings many years of experience in strategic devel­opment and trans­for­mation in the area of payment trans­ac­tions to his new role. The corporate finance specialist has held various positions within the Deutsche Bank Group in recent years. Among other things, he actively supported various strategic M&A trans­for­mation projects of the bank’s private customer business in the Group Devel­opment department of Deutsche Postbank AG and at Deutsche Bank and positioned Pagateq as a BaFin ZAG-licensed payment service provider with its own identity within Deutsche Bank Group.

Gerd Cimiotti, who has been Managing Director of SRC since 2001, will actively support the gener­a­tional change and the handover to Markus Schierack until 2025 and will then retire from management: “One of the biggest challenges for medium-sized companies is the successful gener­a­tional change. At SRC, Markus Schierack is the next gener­ation to take on overall respon­si­bility for the company. I am very confident that Markus will not only lead SRC Security Research & Consulting GmbH into a good economic future, but will also keep the special values of our company alive,” explains Cimiotti.

The time frame was delib­er­ately set to allow for a gradual transition. The SRC share­holders’ meeting would like to take this oppor­tunity to thank Mr. Cimiotti for his trusting cooper­ation and his successful and tireless efforts to develop SRC into a leading IT security compe­tence center.

Markus Schierack already knows SRC very well from his role as Chairman of the SRC Share­holders’ Meeting and will now join the Management Board on August 1. Markus Schierack is looking forward to the challenge that he wants to master together with the employees at SRC: “My heart beats for the company and I have already had the oppor­tunity to get to know SRC well through my work as a repre­sen­tative of a share­holder of SRC Security Research & Consulting GmbH.”

The 43-year-old will be supported by Randolf Skerka, who will be respon­sible for SRC’s auditing business in the future. The current Head of Sales at SRC has been familiar with the company and the auditing business in particular for many years from various roles at SRC. “For me, teams with strong person­al­ities are always important in order to master upcoming challenges. I am therefore grateful to have Randolf Skerka at my side as an extremely experi­enced sparring partner,” says future Managing Director Markus Schierack.

About SRC Security Research & Consulting GmbH

SRC is the joint compe­tence center of the German banking industry for IT security. SRC was founded in 2000 with the support of the four credit industry publishers (Bank-Verlag GmbH, DG-Nexolution eG, S‑Payment GmbH and VÖB ZVD-Processing GmbH) and the leading associ­a­tions of the German credit industry repre­sented on the company’s advisory board (Bundesverband deutscher Banken e.V., Bundesverband der Deutschen Volks­banken und Raiffeisen­banken e.V., Bundesverband Öffentlicher Banken Deutsch­lands e.V., Deutscher Sparkassen- und Giroverband e.V.).

In April 2001, Gerd Cimiotti joined the company’s management and led the expansion of SRC into a leading IT security service provider in Europe. With more than 120 employees, SRC is not only one of the top addresses when it comes to technical innova­tions in payment, but SRC also offers a compre­hensive IT security and audit program to support customers all over the world.

The plan for the future is to further expand both business areas and take advantage of the emerging market oppor­tu­nities. The new management team led by Markus Schierack is an important prereq­uisite for this. The smooth transition in management from Gerd Cimiotti to Markus Schierack also ensures the necessary continuity.

Janine Wolff

The impor­tance of penetration tests for the security of companies

In an increas­ingly digitalized world, the security of corporate networks and sensitive data is of paramount importance.
A proven method for checking the security of systems and uncov­ering vulner­a­bil­ities is to carry out penetration tests.
Penetration tests are simulated attacks on IT infra­struc­tures, appli­ca­tions or networks that aim to uncover security vulner­a­bil­ities before they can be exploited by malicious actors. 

Why penetration tests are essential

Imagine you want to protect your property from unautho­rized access.
You could take all the security measures available, such as installing high fences, alarms and security cameras.
But how can you be sure that an experi­enced burglar could not exploit a vulner­a­bility that you are not aware of?
This is where the penetration test comes into play.
Similar to hiring a profes­sional burglar to test your property, a penetration test simulates targeted attacks to uncover potential vulner­a­bil­ities before they can be exploited by real attackers.
This gives you a realistic insight into your company’s security situation and allows you to take targeted measures to improve it. 

The advan­tages of penetration tests

Carrying out penetration tests offers a number of advan­tages for companies.
On the one hand, it enables a compre­hensive assessment of the security situation and helps to uncover potential vulner­a­bil­ities before they can be exploited by attackers.
In addition, a regularly conducted penetration test helps to strengthen the trust of customers and partners in a company’s security measures.
Last but not least, signif­icant financial and legal risks can be avoided by identi­fying and elimi­nating vulnerabilities. 

What services are available at in connection with penetration tests?

At SRC, we offer compre­hensive penetration testing services tailored to the specific require­ments and needs of our clients.
Our experts carry out penetration tests in various areas, including 1. point-of-sale (POS) systems: POS systems are an important part of many businesses, partic­u­larly in the retail and hospi­tality sectors.
Our penetration tests aim to assess the security of these systems and uncover potential vulner­a­bil­ities that could jeopardize the integrity of transactions.
2. apps: With the increasing use of mobile appli­ca­tions in businesses, it is important to ensure their security as well.
Our app penetration testing focuses on mobile appli­cation security to uncover potential vulner­a­bil­ities that could be exploited by attackers to access sensitive company data or compromise the integrity of the application.
3. web appli­ca­tions: With business processes increas­ingly moving online, web appli­ca­tions have become a favorite target for hackers.
Our web penetration tests identify vulner­a­bil­ities in web appli­ca­tions, including cross-site scripting (XSS), SQL injection and other potential attack vectors.
4. individual systems: In addition to web appli­ca­tions, internal systems and appli­ca­tions are also vulnerable to attack.
Our system penetration tests uncover vulner­a­bil­ities in operating systems, servers, databases and other internal systems to improve the overall security of the organization.
5. infra­structure: Network infra­structure security is critical to protecting sensitive company data.
Our infra­structure penetration tests identify vulner­a­bil­ities in networks, firewalls, routers and other network compo­nents to ensure a high level of security. 

The different methods of penetration testing

At our company, we distin­guish between different approaches to penetration testing.
1. internal vs. external: In internal penetration tests, we imitate potential attacks from within the company network.
This allows us to identify vulner­a­bil­ities that could be exploited by autho­rized users or internal systems.
External penetration tests, on the other hand, simulate attacks on the company network from outside.
The focus here is on finding security gaps that could be exploited by external attackers to gain access to the internal network.
The combi­nation of internal and external tests provides a compre­hensive security assessment and helps to effec­tively combat both external and internal threats.
2. white, gray and black box approaches: Penetration testing is often catego­rized as white box, grey box and black box, depending on how much knowledge is available to the tester about the internal struc­tures of the system.
White box tests include full knowledge of the internal struc­tures of the system.
Grey box tests, on the other hand, give the tester only partial knowledge of the system, which corre­sponds to a more realistic simulation of external attacks.
Black box tests, on the other hand, are performed without knowledge of the internal system in order to test the system’s reaction to a real, unpre­dictable attack.
The choice of approach depends on the specific objec­tives of the test.
White box tests are useful for identi­fying vulner­a­bil­ities in specific system compo­nents, while grey and black box tests check the overall security of the system and simulate realistic scenarios. 

Security in good hands

Our penetration tests are carried out by experi­enced security experts who have extensive knowledge in the areas of infor­mation security and ethical hacking.
With our help, organi­za­tions can proac­tively identify potential security risks and take appro­priate measures to protect their systems and data.
Contact SRC GmbH today to learn more about our penetration testing services and strengthen your organization’s security. 

SRC TeleTrusT
Homepage Admin

SRC joins the German IT Security Associ­ation (TeleTrusT)

SRC joined the German IT Security Associ­ation (TeleTrusT).

The Bundesverband IT-Sicherheit e.V. (TeleTrusT) is a compe­tence network comprising domestic and foreign members from industry, admin­is­tration, consulting and science as well as themat­i­cally related partner organisations.

Due to the perma­nently changing require­ments in the field of IT security, it is important for SRC that its experts regularly inform themselves about and exchange infor­mation on new neces­sities, techniques, processes and regulations.

TeleTrusT offers partic­u­larly good condi­tions for this, since in addition to the exchange of experts from the business world, contact is also estab­lished with politics and science.

SRC will contribute its wide-ranging expertise to the various working groups of TeleTrusT and thus give further signif­i­cance to the status of IT security in Germany and Europe.

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!

BSI Lagebericht 2023
Janine Wolff

The BSI Situation Report 2023: Secure Your Business – Discover Our Solutions.”

The latest Situation Report from the Federal Office for Infor­mation Security (BSI) for the year 2023 paints a picture of the German cyber­se­curity landscape that reveals both challenges and calls to action. As digital­ization progresses in all areas of life, the complexity and number of cyber threats are increasing.

Specific IT security threats in 2023

Partic­u­larly, ransomware attacks aimed at encrypting company data and demanding ransoms are becoming more sophis­ti­cated and are affecting not only large corpo­ra­tions but also increas­ingly smaller and medium-sized businesses as well as public institutions.

Another prominent topic of the report is the potential misuse of Artificial Intel­li­gence (AI). With the rapid devel­opment of AI technologies and their appli­ca­tions, new possi­bil­ities for attacks emerge. AI-powered attacks, including deep fakes and manip­u­lated chatbots, represent a serious threat that can undermine not only infor­mation security but also societal stability.

Geopo­litical tensions, especially the conflict in Ukraine, further demon­strate that cyber­at­tacks are increas­ingly being used as a means of warfare and political influence. These devel­op­ments are not limited to state actors but also affect the economy and civil society. The BSI empha­sizes that security in cyber­space is no longer just a matter of technical defense but requires a collective societal effort.

The BSI’s recom­men­dation to strengthen “cyber resilience” reinforces the necessity of being proactive and preventive. This means that companies and author­ities must not only react to attacks but also improve the resilience of their systems in advance.

This is where the expertise of SRC GmbH comes in, a company that specializes in security needs in the digital age.

How SRC can help establish cyber resilience

  • Risk analysis and prevention: SRC offers individual risk analyses to help companies identify and address vulner­a­bil­ities before they can be exploited.
  • Security archi­tecture and design: By designing robust security archi­tec­tures, SRC helps ensure that their clients’ systems can withstand advanced threats.
  • Training and awareness: SRC organizes training for employees to increase awareness of cyber­se­curity and ensure that security policies are under­stood and followed.
  • Regulatory compliance and standards: SRC advises on regulatory require­ments and helps companies meet legal and normative standards.
  • Innovation and technology consulting: With expertise in modern technologies such as blockchain and AI, SRC develops innov­ative solutions that are not only secure but also forward-looking.
  • Emergency planning and response: In the event of a cyber­attack, SRC assists with rapid response and deployment of emergency plans to minimize damage and maintain business operations.

Use the insights from the BSI Situation Report 2023 as a decisive impulse to specif­i­cally review and optimize your cyber­se­curity measures – SRC GmbH is ready to work with you to strengthen critical security areas and build resilience against current and future cyber threats.

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.

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.

IT Security Act 2.0 approved by the Bundesrat (Upper House)
Janine Wolff

SRC GmbH: Pioneer in BSZ certi­fi­cation with expansion of the team of experts

In the following article you will learn more about how the SRC GmbH has been acting as a recog­nized test center for the BSZ since September 2021 and what important devel­op­ments and expertise it offers in this area.

Accel­erated Security Certi­fi­cation (BSZ): An Introduction

The BSZ is a procedure offered by the BSI in Germany to prove the security of IT products. It was intro­duced to give manufac­turers a faster way to demon­strate the security of their products with a BSI certificate. This assessment aims to ensure that the product meets the security require­ments of the BSI and offers end users an appro­priate level of protection. Compared to the conven­tional certi­fi­cation according to Common Criteria (CC), the BSZ offers the advantage of faster certi­fi­cation, easier to plan evalu­ation times, and a signif­i­cantly reduced documen­tation effort for the manufac­turer. SRC is a testing center for accel­erated security certi­fi­cation (BSZ) recog­nized by the Federal Office for Infor­mation Security (BSI) and was one of the first recog­nized certi­fi­cation bodies at all.

The road to security: BSZ versus CC

The procedure only allows a single run, i.e. the product to be evaluated may not be changed during the evalu­ation. This greatly speeds up the process overall, but there is always a risk that products will fail the first attempt and therefore not receive a certificate. In this case, however, a new certi­fi­cation procedure can be requested from the BSI at any time.

Under the direction of Peter Jung: The first steps of the SRC with BSZ

Under the project management of Peter Jung, who has been respon­sible for the BSZ at SRC from the start, SCR has since evaluated the Lancom 1900EF VPN router, which was also the first BSZ product ever, and then the secunet high-speed connector. As soon as this is evaluated, we will report on it in another article.

New expertise at SRC: Tim Hirschberg and Dr. Matthieu Felsinger

We are happy to announce that since May 2023 the SRC has been formed with Tim Hirschberg (BSZ evaluator) and Dr. Matthias Heuft (BSZ evaluator) and Dirk Feldhusen (BSZ evaluator for cryptog­raphy) — strengthen.

The BSZ certi­fi­cation in detail: concen­tration on promises of security

The BSZ certi­fi­cation focuses on verifying the safety perfor­mance promised by the manufac­turer. The actual certi­fi­cation is carried out after the product has been evaluated by a test center recog­nized by the BSI, such as the SRC. The resulting test report serves the BSI as a basis for awarding the certificate.

The path to the certificate: the verifi­cation process at SRC

The evalu­ation takes place within a fixed timeframe (about 2–3 months) that depends on the complexity of the product. The evalu­ation services include checking the promised security function­ality (conformity tests) and the instal­lation instruc­tions as well as penetration tests, in which the effec­tiveness of the technical security measures of the product is checked under realistic attack scenarios.

Cryptocur­rency ECB Digital EuroA Holistic Review: Cryptog­raphy and Beyond

The assessment of the imple­mented crypto­graphic proce­dures is also part of the compre­hensive testing process that an IT product has to go through in order to receive the BSZ certification.

A look into the future of safety certification

At SRC GmbH, we are proud of our role as a recog­nized testing body for accel­erated security certi­fi­cation (BSZ) and of contin­u­ously promoting security standards in the IT industry. With our experi­enced team and commitment to innovation, we will continue to help ensure the security of IT products.

If you would like to learn more about our BSZ certi­fi­cation services or have any questions, please do not hesitate to contact us. Together we can meet the safety require­ments of your products and pave the way for certi­fi­cation. We look forward to working with you and shaping the future of safety certification.