For companies that handle cardholder data, adhering to the Payment Card Industry Data Security Standard (PCI DSS) is crucial for ensuring compliance, establishing a robust cybersecurity posture and safeguarding payment data.
One of the key requirements of compliance with PCI DSS is conducting regular penetration tests and vulnerability scans – two common proactive measures to identify and remediate security vulnerabilities before they can be exploited by threat actors.
In this guide, we will delve into the importance of PCI penetration testing and vulnerability scanning for merchants and businesses handling card payments. We will explore the key components of PCI DSS penetration testing, discuss the requirements and best practices, and provide valuable tips for ensuring a successful and robust security scanning and pentesting strategy.
Who is the target audience for this PCI penetration testing guide?
We crafted this guide with the intention of being an authoritative source of information based on our experience working in PCI DSS penetration test audits. We expect to offer relevant insights to the following groups of individuals who may need to procure PCI pentesting services:
- Executive personnel in charge of IT security in an organization (CISO, VP of security, CIO, CTO)
- Auditors and compliance officers
- Cybersecurity professionals, including security engineers and analysts (AppSec, SecOps, InfraSec, etc.)
- Engineering managers and product owners who are involved in a PCI compliance project
What is PCI penetration testing?
PCI penetration testing specifically focuses on evaluating the security of an organization’s cardholder data environment (CDE), ensuring compliance with the PCI DSS requirements. The main objectives of PCI penetration testing include:
- Identifying exploitable vulnerabilities: Uncover security weaknesses within the CDE that could be exploited to gain unauthorized access, compromise systems, or exfiltrate sensitive payment data.
- Validating security controls: Assess the effectiveness of implemented security measures and verify that they are functioning as intended to protect cardholder data.
- Maintaining compliance: Demonstrate adherence to PCI DSS requirements and showcase a commitment to maintaining a strong cybersecurity posture.
- Risk prioritization: Evaluate the severity of identified vulnerabilities and prioritize remediation efforts based on the potential impact on the organization’s security.
- Continuous improvement: Regularly assess the CDE to stay ahead of evolving threats and adapt security strategies to better protect against future attacks.
Key components of PCI penetration testing
Before initiating a PCI penetration test, it is essential to define the scope of the test, which includes identifying all relevant systems, networks, and applications that store, process, or transmit cardholder data.
The cardholder data environment (CDE) comprises all components that directly or indirectly interact with cardholder data, including servers, databases, applications, APIs, network devices, and endpoints.
It is recommended to create an inventory of all in-scope systems and ensure that the scope of your PCI DSS penetration test encompasses the entire CDE to maintain a comprehensive security posture.
External and internal penetration testing (networks and applications)
PCI DSS penetration testing should evaluate both external and internal attack surfaces to identify potential vulnerabilities and validate security controls, following the pentesting guidance outlined by the PCI Council.
External testing targets systems and services in the perimeter that are accessible from the internet, such as public-facing networks, servers, web applications, and APIs. This type of testing helps uncover security risks that could be exploited by external attackers to gain unauthorized access to cardholder data or disrupt services.
Internal testing, as the name implies, focuses on the organization’s internal network, applications, and critical systems in the CDE scope. This testing aims to identify flaws that could be exploited by insiders and threat actors that have breached the external perimeter.
Network segmentation testing
Segmentation testing is an essential component of PCI DSS, specifically targeting organizations that implement network segmentation to isolate their CDEs from other networks. The primary goal of segmentation testing is to verify the effectiveness of the implemented controls, ensuring they are robust enough to enforce measures to prevent unauthorized access to the CDE.
Segmentation tests must be executed twice per year. The PCI Security Council created a comprehensive guidance on segmentation that is the authoritative reference about the topic.
Documentation and reporting
Maintaining detailed documentation and reporting of the assessment is crucial for demonstrating PCI DSS compliance. The penetration test report should include clear information about the test scope, penetration testing methodology, details about all identified vulnerabilities, remediation recommendations, and retest results. Organizations should retain these reports as evidence of compliance during PCI DSS audits.
In our experience, some auditors may also ask the report to contain the exact date and time a vulnerability was identified and exploited, as well as the same information for when it was marked as fixed after the retest.
Understanding PCI penetration testing requirements
PCI DSS 3.2.1 Requirement 11 (Regularly test security systems and processes) is the one that specifically addresses penetration testing within the CDE environment for organizations that handle cardholder data.
For the purposes of pentesting, the following subitems of Requirement 11 are important to be addressed:
PCI Requirement 11.3 is the cornerstone of penetration testing within the PCI DSS 3.2.1, ensuring organizations safeguard their CDEs through comprehensive and regular security assessments. The norm says that security testing must be performed based on recognized industry methodologies – it explicitly mentions NIST SP 800-115, but others such as OSSTMM, OWASP and PTES also do apply, per 4.4 in Penetration Testing Guidance.
The requirement is divided into three primary components: addressing network penetration testing, internal penetration testing, and segmentation controls.
Firstly, Requirement 11.3.1 focuses on external network penetration testing, emphasizing that organizations must perform tests on their internet-facing servers and networks to identify vulnerabilities that could be exploited by external adversaries. By conducting a yearly network penetration test, businesses can proactively discover security weaknesses and implement appropriate measures to protect sensitive cardholder data.
Next, Requirement 11.3.2 pertains to internal penetration testing, requiring organizations to evaluate their internal systems, networks, and applications for potential security gaps. Internal penetration testing plays a crucial role in uncovering risks that may not be visible from the outside but could be exploited by an insider or an attacker who has already gained access to the internal network. It needs to be done at least once per year.
Requirement 11.3.3 addresses retesting and emphasizes the need for timely remediation.
Finally, Requirement 11.3.4 addresses the need to test segmentation controls if an organization uses network segmentation as a method to isolate its CDE from other networks. This requirement ensures that network isolation controls are functioning effectively and that there is no unauthorized access to the CDE.
Other security-relevant requirements of item 11 are the following:
Requirement 11.1 intends to ensure the security of an organization’s wireless networks within or connected to the cardholder data environment. The main focus is on rogue access points, and sweeps must be performed on a quarterly basis.
Requirement 11.2 defines rules for running internal and external network vulnerability scans at least quarterly and after any significant change in the network. There are rules where there’s the need to obligatorily use (or when it’s not mandatory) a PCI SSC Approved Scanning Vendor to perform such scans.
There’s also Requirement 6 (Develop and maintain secure systems and applications) of PCI DSS; it has equal importance in regard to security testing, especially requirements 6.5.1 through 6.5.6 (based on secure development practices) and 6.6 (testing).
Requirement 6.6 explicitly mentions that companies seeking PCI DSS compliance must perform security evaluations of public-facing web applications (and APIs, per 4.2.1 Application Layer) using manual testing or automated tools for application vulnerability scanning at least annually and after any relevant changes.
OWASP Top 10 and OWASP ASVS are the most popular methodologies for application layer testing and security of web applications/APIs, without a doubt being the most relevant penetration test methodology for this item.
An important note above is that the vulnerability scans in Requirement 11.2 are not the same as the assessments needed to address 6.6.
In PCI 4.0, the requirement for web application security testing has changed to Requirement 6.4 (Public-facing web applications are protected against attacks).
We have created an infographic to visually illustrate these requirements:
Frequency of PCI penetration tests
As per PCI data security standards, organizations must conduct pentesting at least annually or whenever significant changes are made to their infrastructure, such as new system implementations, major upgrades, or modifications to network topology.
Conducting regular pentests ensures that security vulnerabilities introduced by changes in the environment are identified and addressed promptly, maintaining a continuous security posture.
Remediation and retesting process
Upon completion of the penetration test, organizations should prioritize the remediation of identified security issues based on their severity and potential impact on the CDE. Once the vulnerabilities have been addressed, a retest should be performed to validate the effectiveness of the implemented security measures and ensure that the issues have been successfully mitigated.
Looking for a pentest provider? Let us challenge your cyber defenses.
Talk to our experts for a custom quote
What is the difference between a PCI penetration test and a regular pentest?
A PCI penetration test and a regular penetration test share many similarities in terms of methodology and objectives, but they have important differences that need to be taken into account. While both PCI penetration tests and regular penetration tests aim to identify issues and improve an organization’s security posture, the main difference lies in the scope and focus of the tests, as well as the mandatory frequency of pentest.
The most important differences between a PCI DSS penetration test and a regular penetration test are explained in detail below:
Scope and focus
- PCI Penetration Test: A PCI pentest specifically focuses on the cardholder data environment (CDE) within an organization, which includes all systems, networks, and applications that store, process, or transmit cardholder data.
- Regular Penetration Test: A regular penetration test may have a broader scope, encompassing an organization’s entire IT infrastructure, including networks, applications, systems, and even the human element. The primary objective of a regular penetration test is to identify vulnerabilities and security weaknesses across the organization, regardless of whether they are related to cardholder data or not.
- PCI Penetration Test: Pentesting is a mandatory requirement for organizations that handle cardholder data to comply with PCI DSS. The results of these tests are often used as evidence of compliance during PCI DSS assessments.
- Regular Penetration Test: While regular penetration testing is considered a best practice in cybersecurity, it may not be an obligatory compliance requirement like it is in PCI DSS. Various regulatory frameworks and industry standards, such as SOC 2, GDPR, HIPAA, and ISO 27001, suggest organizations conduct regular penetration tests as part of their overall security program, but they are not mandatory.
Remediation and reporting
- PCI Penetration Test: The remediation and reporting processes for PCI penetration tests are more focused on addressing vulnerabilities that could impact cardholder data and demonstrating compliance with PCI DSS requirements. Retesting is typically required to validate the effectiveness of the implemented security measures and ensure that the vulnerabilities have been successfully mitigated.
- Regular Penetration Test: The remediation and reporting processes for regular penetration tests involve addressing a wider range of vulnerabilities and security weaknesses. Retesting is encouraged but may not be specifically required by a compliance framework.
- PCI Penetration Test: According to Requirement 11.3, companies are required to perform pentesting at least annually or after any significant infrastructure or application changes.
- Regular Penetration Test: As there are no mandatory requirements, frequency is up to your organization’s risk appetite and pentest roadmap. Nevertheless, organizations that have mature security testing practices do perform penetration testing with a frequency of at least once every 12 months.
Key differences between PCI DSS 4.0 and PCI DSS 3.2.1
Penetration testing requirements outlined by PCI 4.0 remains largely unchanged compared to 3.2.1. In the latest version of the standard, there have been changes in the order of items, such as Requirement 11.3 in 3.2.1 now becoming Requirement 11.4 in 4.0.
There have been important changes in the way the requirements are communicated, adding more clarity to the process and decreasing the likelihood of ambiguous interpretations.
For instance, it now states, “Testing from inside the network (or ‘internal penetration testing’) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks” and “Testing from outside the network (or ‘external penetration testing’) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures.”, to properly define what PCI means when it says internal and external pentesting and from which vantage point it must be executed.
Another item worth mentioning is “184.108.40.206 Internal vulnerability scans are performed via authenticated scanning” – before that, there was no explicit requirement for grey-box automated testing or that scans needed to be authenticated; now it ensures the vulnerability scanner covers a larger surface.
Common tools used in PCI penetration testing
In PCI DSS penetration testing, a wide range of tools is employed to assess the security of the CDE environment and identify potential vulnerabilities that could be exploited by attackers.
These tools play a crucial role in evaluating various aspects of an organization’s security posture, including network configurations, web applications, wireless networks, and system vulnerabilities. The choice of tools may vary depending on the specific needs and goals of the penetration test, but some commonly used tools in a PCI penetration test include:
- Nmap: For network scanning and discovery of open ports and services, as well as segmentation checks.
- Nessus: To automate the process of identifying known vulnerabilities in systems, networks, and applications. It can also be used for ASV scans as it can perform PCI vulnerability scanning.
- Metasploit: A comprehensive exploitation framework for developing and executing exploit code against identified vulnerabilities.
- Burp Suite: A powerful web application security testing tool with features such as intercepting proxy, web vulnerability scanning, and session manipulation.
- Wireshark: A network protocol analyzer for capturing and analyzing network traffic, providing valuable insights into potential vulnerabilities and attack vectors. Particularly useful to verify whether card data is traversing the network unencrypted.
- Memory scraping tool: A regex-based RAM scrapping tool can be useful in PCI security testing to identify credit card data temporarily stored in the memory of a CDE-located server once they’re compromised by the pentester.
The list above is non-exhaustive, and several other tools can be used depending on the needs of the assessment.
Engaging a qualified penetration testing company – how to select the best pentest provider
To ensure the accuracy and reliability of penetration test results, organizations should engage a qualified penetration tester with relevant experience and expertise in the field.
Organizations often choose to work with external penetration testing firms, and it is recommended to engage a qualified penetration tester or an organization with certified professionals who are familiar with PCI DSS requirements and industry best practices.
To help organizations navigate the nuances of selecting a penetration testing provider, we have created a complete guide with insights for choosing the right pentest company for their needs.
How can we help your organization’s PCI penetration testing requirements?
At Blaze, we have our roots in providing penetration testing services for the financial sector and banking and payment industries, meaning we have performed dozens of PCI pentesting assessments throughout the years.
Our team of experienced and certified penetration testers is well-versed in the latest emerging threats, and industry best practices and knows what is the most suitable approach and type of pentest to ensure an extensive security assessment of your cardholder data environment.
If you’re ready to invest in the security and compliance of your business and are looking for a pentesting provider that has relevant experience in performing assessments for PCI DSS, we invite you to get in touch with our experts to discuss how our CREST-accredited penetration testing assessments can benefit your organization.
In this guide, we have discussed the importance of PCI penetration testing, its key components, requirements, best practices, and tips for a successful test, as well as how to find the right supplier for your PCI pentest. By understanding and implementing these practices, organizations can effectively manage their cybersecurity risks, safeguard cardholder data, and maintain compliance with PCI security standards.
It’s vital to appreciate the pivotal role PCI DSS penetration tests play in every merchant and business’s cybersecurity defense strategy. These tests are not only integral to meeting and maintaining key PCI security standards, such as Requirements 11.3 and 6.6 in PCI 3.2.1 and Requirements 11.4 and 6.4 in PCI 4.0, but they also pave the way for comprehensive cybersecurity risk mitigation and robust protection of cardholder data.
Performing penetration testing, whether it be a standard pen test or a more focused application penetration test, is an annual requirement for PCI DSS. However, it also needs to be conducted following every major change in networks, servers, and systems. By conducting these tests, businesses can proactively identify potential vulnerabilities and address them, thereby fortifying their cyber defenses.
The technical complexities surrounding PCI DSS penetration tests necessitate a comprehensive understanding, careful application, and, most importantly, the selection of a capable and experienced supplier for your PCI pentest. This choice of partner is crucial in not only ensuring compliance but also in the successful strengthening of your organization’s overall cybersecurity infrastructure.
We encourage merchants and businesses that handle cardholder data to prioritize regular penetration testing as a critical component of their cybersecurity strategy.
Does PCI require penetration testing?
Yes, PCI requires mandatory penetration testing per Requirements 11.3 and 6.6 in PCI 3.2.1 and Requirements 11.4 and 6.4 per PCI 4.0.
How often does PCI require penetration testing?
PCI pentesting is mandatory once a year or at every major change in networks, servers and systems.
When does PCI DSS 4.0 go into effect?
PCI DSS 4.0 goes into effect on March 31, 2024, and organizations have until March 31, 2025 to phase in new requirements.