Beyond Compliance: Leveraging Penetration Testing and Training in PCI DSS
This article is authored by Software Secured, a penetration testing provider and proud GRSee partner.
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.
What is a penetration test?
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.
What is PCI DSS?
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.
In order 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 these following crucial penetration testing requirements.
Requirements:
Requirement 11: Test 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 that 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 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 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.
How penetration testing helps fulfill PCI DSS requirements
Attackers spend a lot of time finding external and internal vulnerabilities to obtain access to cardholder data and then to exploit that data, which may lead to your clients personal 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 to 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 in accordance with PCI DSS to simulate attacker behavior and discover vulnerabilities in their environment.
Common Security Questions for PCI DSS Compliance
How do you scope for PCI DSS? What is included?
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 necessary 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:
- 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. - Identify Cardholder Data (CHD)
Clearly 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. - 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. - 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. - 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. - 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. - 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. QSAs are independent entities authorized by the PCI Security Standards Council to assess PCI DSS compliance. GRSee offers Qualified Security Assessor’s (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 ensuring 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.
Does OWASP top 10 training designed for developers satisfy PCI training requirements?
PCI DSS requires following secure coding guidelines and evidence that developers educate themselves on the latest best practices. OWASP 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.
How can you work with large vendors when you are just starting or are new to 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. SMB’s need compliance in order 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 around the vulnerabilities and what they are, and how each vulnerability was created (original root cause). Each organization varies, but those who are vetting vendors beyond compliance will ask more details about the risk to ensure they aren’t putting their company reputation or client data at risk.