Leveraging Penetration Testing to Meet PCI DSS Compliance Standards

TL;DR:

• PCI DSS compliance requires vigilance and proactive security measures.
• Penetration testing is crucial for fulfilling PCI DSS requirements.
• Scoping for PCI DSS compliance involves identifying cardholder data and defining the scope.
• OWASP top 10 training for developers can help satisfy PCI training requirements.
• Working with large vendors as a new organization requires understanding their security requirements and providing the necessary documentation.

Maintaining and earning PCI DSS compliance isn’t just a box-ticking exercise—it’s a dynamic process that demands vigilance, adaptability, and a proactive stance surrounding security posture. For both large and small organizations PCI DSS can be a challenge. 

In this blog, we’ll break down the importance of penetration testing, its role in fulfilling PCI DSS requirements, common security questions, and why staying one step ahead ensures not only compliance but also the continued trust of your customers.

Understanding the Purpose and Process of a Penetration Test for PCI DSS Compliance

A penetration test is a type of security test designed to identify vulnerabilities in your computer system, network, or application that an attacker could exploit. By having a third party perform a penetration test, you’ll get an overview of your overall security posture, including vulnerabilities identified, plus detailed replication and remediation suggestions so you can improve your security program.

Penetration Testing as a Service (PTaaS) is an extended, more comprehensive form of penetration testing that provides year-round coverage. While a one-time pentest is great for providing a baseline of your security posture or compliance, it isn’t always enough. PTaaS will test your application multiple times per year, plus provide security consulting and fix verification testing along the way. 

Risk reduction is the ultimate goal of a penetration test, which helps fulfill PCI DSS requirements.

Exploring the Significance of PCI DSS in Data Security Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards formed in 2004 by Visa, MasterCard, Discover Financial Services, JCB International and American Express. Governed by the Payment Card Industry Security Standards Council (PCI SSC), the compliance scheme aims to secure credit and debit card transactions against data theft and fraud. While the PCI SSC has no legal authority to compel compliance, it is a requirement for any business that processes credit or debit card transactions.

To fulfill PCI DSS requirements, you must complete a penetration test. This can look different depending on your application, network and overall infrastructure – as there are various kinds of penetration tests needed. A security assessor wouldn’t sign a PCI DSS audit without the following crucial penetration testing requirements. 

Key Requirements for Achieving PCI DSS Compliance

Requirement 11: Test the security of systems and networks regularly

11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.

11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity, and includes:

• Industry-accepted penetration testing approaches.
• Coverage for the entire cardholder data environment (CDE) perimeter and critical systems.
• Testing from both inside and outside the network.
• Testing to validate any segmentation and scope-reduction controls.
• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
• Network-layer penetration tests encompass all components that support network functions as well as operating systems.
• Review and consideration of threats and vulnerabilities experienced in the last 12 months.
• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
• Retention of penetration testing results and remediation activities results for at least 12 months.

11.4.2 Internal penetration testing is performed:

• Per the entity’s defined methodology,
• At least once every 12 months
• After any significant infrastructure or application upgrade or change
• By a qualified internal resource or qualified external third-party
• Organizational independence of the tester exists (not required to be a QSA or ASV).

11.4.3 External penetration testing is performed:

• Per the entity’s defined methodology
• At least once every 12 months
• After any significant infrastructure or application upgrade or change
• By a qualified internal resource or qualified external third party
• Organizational independence of the tester exists (not required to be a QSA or ASV).

11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:

• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.
• Penetration testing is repeated to verify the corrections.

11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:

• At least once every 12 months and after any changes to segmentation controls/methods
• Covering all segmentation controls/methods in use.
• According to the entity’s defined penetration testing methodology.
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.
• Confirming the effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).
• Performed by a qualified internal resource or qualified external third party.
• Organizational independence of the tester exists (not required to be a QSA or ASV).

11.4.6 Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:

• At least once every six months and after any changes to segmentation controls/methods.
• Covering all segmentation controls/methods in use.
• According to the entity’s defined penetration testing methodology.
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.
• Confirming the effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).
• Performed by a qualified internal resource or qualified external third party.
• Organizational independence of the tester exists (not required to be a QSA or ASV).

11.4.7 Additional requirement for multi-tenant service providers only: 

• Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.

Leveraging Penetration Testing to Meet PCI DSS Compliance Standards

Attackers spend a lot of time finding external and internal vulnerabilities to obtain access to cardholder data and then exploit that data, which may lead to your client's data being compromised. This testing allows the entity to identify any immediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and system components from such attacks.

Internal penetration testing serves two purposes. Firstly, just like an external penetration test, it discovers vulnerabilities and misconfigurations that could be used by an attacker that had managed to get some degree of access to the internal network, whether that is because the attacker is an authorized user conducting unauthorized activities, or an external attacker that had managed to penetrate the entity’s perimeter. Secondly, internal penetration testing also helps entities discover where their change control process failed by detecting previously unknown systems. Additionally, it verifies the status of many of the controls operating within the CDE.

When a company uses segmentation controls to isolate the CDE from internal untrusted networks, the security of the CDE is dependent on that segmentation functioning. Using penetration testing tools and techniques to validate that an untrusted network is indeed isolated from the CDE. Entities need to conduct penetration tests following PCI DSS to simulate attacker behaviour and discover vulnerabilities in their environment. 

Common Security Questions for PCI DSS Compliance 

Determining Scope and Inclusions for PCI DSS Compliance through Penetration Testing

Scoping may look different depending on your organization, application, data sensitivity, security posture and relevancy to PCI DSS. Scoping for PCI DSS compliance is a crucial step for businesses to ensure they are meeting the requirements without unnecessary resource allocation. Larger organizations may have multiple, larger applications and/or legacy systems, which you would need additional efforts to segment for compliance. 

Here’s a step-by-step guide on how to scope for PCI DSS compliance requirements:

1. Determine Your Business Objectives

Start by understanding why your business needs to be PCI DSS compliant. This could be because you accept credit card payments, and compliance is mandatory for your industry or to build trust with customers. It is also important to take security into account, are you interested in meeting compliance requirements, or going beyond compliance and focusing on your security posture in its entirety given how valuable the data is that’s accessed, stored and processed within the financial sector? 

2. Identify Cardholder Data (CHD)

Identify and document where cardholder data (CHD) is collected, stored, transmitted, or processed within your organization. CHD includes primary account numbers (PANs), cardholder names, expiration dates, and other sensitive information.

3. Define the Scope:

Limit the scope of PCI DSS compliance to the systems, people, and processes that handle CHD. This is often referred to as the CDE. The goal is to minimize the systems that fall within the scope.

4. Assess Third-Party Relationships:

Identify any third-party service providers, such as payment processors or cloud providers, that interact with CHD. Ensure they are also compliant and that their services are included in your scope.

5. Review Payment Channels:

Evaluate all payment channels in your organization, including e-commerce websites, point-of-sale (POS) terminals, mobile apps, and any other methods used to accept payments.

6. Determine Applicable Requirements:

Review the PCI DSS requirements (currently consisting of 12 requirements and numerous sub-requirements) and identify which ones are relevant to your scope. Not all requirements may apply if certain systems or processes are out of scope.

7. Engage Qualified Security Assessors (QSAs):

Engaging a Qualified Security Assessor (QSA) to validate compliance means finding a partner who understands where your business is coming from and working towards it. QSAs are independent entities authorized by the PCI Security Standards Council to assess PCI DSS compliance. GRSee offers Qualified Security Assessors (QSAs) to validate your compliance audit. 

What type of pentest do I need for PCI DSS Compliance? 

Penetration requirements for PCI DSS are quite specific compared to other security compliance frameworks. A QSA will need to see evidence of an application pentest, both internal and external infrastructure pentests as well as ensure a segmentation test is conducted.

For those companies who have adopted PCI DSS version 4, biannual penetration testing is required, and segmentation testing in some cases. 

Understanding the Unique Aspects and Scope of Penetration Testing for PCI DSS Compliance

PCI penetration testing is distinct from standard penetration testing in several key aspects. The scope of PCI tests is specifically tailored to focus on the cardholder data environment and compliance with PCI DSS requirements. This targeted approach ensures that all systems and processes handling sensitive payment card information are thoroughly examined. The duration of PCI penetration tests can vary significantly, ranging from one week for simpler environments to over a month for more complex infrastructures. This extended timeframe allows for a comprehensive assessment of security controls, vulnerabilities, and potential risks within the cardholder data ecosystem. The compliance-driven nature of PCI penetration testing also necessitates adherence to specific methodologies and reporting standards, ensuring that the results align with PCI DSS requirements and can be effectively used to demonstrate compliance to auditors and stakeholders.

Evaluating the Suitability of OWASP Top 10 Training for PCI DSS Training Requirements

PCI DSS requires following secure coding guidelines and evidence that developers educate themselves on the latest best practices. OWASP's Top 10 training focuses on the latest vulnerabilities leading to the most damaging cybersecurity breaches, and how to avoid introducing them into code in the first place. The cyber security landscape is forever changing, and attackers are constantly honing their skills and inventing new attack strategies. Therefore, per the PCI DSS 6.5 requirement, your developers must receive regular security training at least once a year. There are new versions of PCI DSS training based on new threats, and it is important to remain up to date with the latest training modules to help prevent security incidents. Software Secured offers OWASP top 10 training to help your developers keep up to date with the latest secure coding best practices.

Navigating Collaboration with Major Vendors in the Initial Stages of PCI DSS Initiatives

Every organization requires different security requirements. Each bank is different in terms of what they are looking for from vendors. Small and medium businesses can often struggle to answer vendor security questionnaires based on their understanding of risk, and security requirements that haven’t been put in place. SMBs need compliance to close enterprise deals, among other tools and initiatives like training and penetration testing. For organizations with less experience with security, it is important to know what vendors are looking for when you are detailing your security posture.

Banks are looking for penetration testing reports and certificates to show all vulnerabilities and security gaps are closed within your SLAs. They also want to know more information about the vulnerabilities, what they are, and how each vulnerability was created (original root cause). Penetration testing for PCI DSS is crucial for demonstrating the closure of vulnerabilities and security gaps within SLAs. Each organization varies, but those who are vetting vendors beyond compliance will ask for more details about the risk to ensure they aren’t putting their company reputation or client data at risk.