PCI compliance establishes specific expectations for penetration testing, but there are several things an organization must consider to ensure it is getting the value and assurance it expects from the engagement.
For regulated organizations, selecting enterprise penetration testing services should involve more than comparing prices and receiving a final report. Security leaders should understand what is being tested, how it will be tested, who is performing the work, and what happens after vulnerabilities are discovered.
Penetration Testing Is Not Vulnerability Scanning
Many organizations believe vulnerability scanning and penetration testing are the same thing. Some penetration testing companies even sell what is essentially a vulnerability scan as a “penetration test,” but the two are not the same thing.
A vulnerability scanner searches systems for known vulnerabilities, missing patches, configuration problems, exposed services, and other identifiable weaknesses. Scanning is valuable and should be part of the engagement, but it is only one part of penetration testing.
Penetration testing goes further. A penetration tester evaluates whether weaknesses can actually be exploited and what an attacker might accomplish as a result. This can include combining several weaknesses that individually appear relatively minor but together create a significant attack path.
A scanner, for example, might identify several issues on an Internet-facing system. A penetration tester may determine that one of those weaknesses can be exploited to obtain unauthorized access or reach sensitive information.
That distinction is important, especially when providing evidence to a QSA.
Understand What PCI Requires
PCI DSS includes penetration-testing requirements under Requirement 11. Organizations need a defined penetration-testing methodology and testing that appropriately evaluates threats to the cardholder data environment.
It is important to define the scope correctly. A penetration test that examines only a few Internet-facing IP addresses may not provide sufficient coverage of the CDE. Depending on the environment, testing may also need to include internal systems, applications, APIs, segmentation controls, and other infrastructure.
PCI Scope Should Drive the Test
Before testing begins, the organization and penetration-testing provider should clearly identify the cardholder data environment and the systems that could affect its security.
Depending on the environment, that may include Internet-facing systems, internal networks, payment applications, web applications, APIs, authentication infrastructure, security devices, administrative systems, and segmentation controls.
Segmentation deserves particular attention. If an organization uses network segmentation to reduce PCI scope, it should be able to demonstrate that systems considered out of scope cannot improperly access the cardholder data environment.
The goal should not be to create the smallest possible penetration test. It should be to create a defensible test that accurately represents the environment and the risks being evaluated. Remember, you may ultimately need to defend the scope and results of this penetration test to a QSA.
Web Applications Need More Than an Automated Scan
For many organizations, payment environments include customer-facing websites, payment portals, APIs, or other web applications. This makes web application security testing an important component of the assessment.
Automated tools are useful, but they cannot replace a skilled tester who understands how an application is supposed to operate.
Manual testing can identify weaknesses involving authentication, authorization, session management, privilege boundaries, API security, input handling, and business logic.
Business-logic flaws demonstrate why this matters. An application may function exactly as programmed while still allowing a user to perform an action that should not be permitted. Automated scanners often struggle to identify these types of issues.
Organizations should ask potential penetration-testing providers how much of their application testing is performed manually versus through automated tools.
Ask Who Is Actually Performing the Test
The company name on the proposal matters less than the people actually performing the work.
Security leaders should ask about the experience of the assigned testers and whether they have worked with similar environments and technologies.
A tester evaluating a payment application should understand web application security. Someone assessing segmentation should understand network architecture and firewall controls. A tester working inside a regulated enterprise should also understand how to conduct testing without creating unnecessary operational risk.
Establish Rules of Engagement
Penetration testing intentionally generates activity that may look malicious to security systems and, depending on the environment, could create operational risk.
Every engagement should therefore have documented rules of engagement.
The organization and testing provider should agree on the authorized systems, testing schedule, permitted and prohibited techniques, production restrictions, emergency contacts, stop procedures, handling of credentials and sensitive information, and escalation requirements.
For regulated enterprise security, these are not simply administrative details. They are part of conducting testing safely and responsibly.
The testing team should also know what to do if it discovers something requiring immediate attention. Evidence of an active compromise, exposed sensitive information, or a critical vulnerability should not have to wait for the final report.
The Report Should Help You Fix the Problem
A penetration-test report should provide more than a list of vulnerabilities.
Security teams need enough information to understand what was discovered, why it matters, what systems are affected, how the issue was validated, and what should be done about it.
Useful findings should include supporting evidence, affected assets, severity, potential impact, and practical remediation guidance. However, remember that the penetration tester does not know your environment as well as you do. It is ultimately up to the organization to take the information in the report, evaluate it in the context of its environment, and develop an appropriate remediation plan.
The organization needs a process for assigning findings, researching appropriate fixes, correcting vulnerabilities, tracking remediation, and validating that the fixes actually worked.
Without that process, the penetration test risks becoming a report that sits on a shelf until someone asks for it during the next audit.
Retesting Matters
Retesting provides validation that a vulnerability has been corrected or that appropriate mitigating controls have been implemented to reduce the risk. This can also be important evidence when demonstrating remediation to a QSA.
When selecting a penetration-testing provider, determine whether remediation testing is included, how many rounds of retesting are available, how long the retesting window remains open, and what evidence will be provided afterward.
This is particularly important when penetration testing supports a compliance requirement. The organization needs to demonstrate not only that weaknesses were discovered, but that appropriate corrective action was taken.
Look Beyond PCI
PCI may be the reason for a penetration test, but it should not necessarily define the limits of the organization’s security thinking.
Many organizations operate under several regulatory and contractual obligations simultaneously.
A healthcare organization, for example, may have payment card information and protected health information within the same broader technology environment. While PCI and HIPAA have different requirements, the same technical weakness could potentially expose both types of information.
For organizations concerned with healthcare data security, financial information, personal information, or other sensitive data, penetration testing can provide value beyond the immediate PCI requirement.
Choosing an Enterprise Penetration Testing Provider
When evaluating enterprise penetration testing services, security leaders should consider several factors together rather than making the decision primarily on price.
A qualified provider should be able to explain its methodology, understand PCI requirements, conduct meaningful manual testing, demonstrate experience with the technologies being assessed, establish appropriate rules of engagement, provide actionable reporting, and support remediation validation.
For regulated organizations, the provider should also understand the realities of environments where downtime, sensitive information, regulatory obligations, and third-party dependencies matter.
The right penetration test should produce information that helps the organization make better security decisions.
Penetration Testing Should Validate Security
PCI compliance may require penetration testing, but you can use the same penetration test for other security improvements.
A well-designed penetration test gives security leaders an opportunity to evaluate the environment from an attacker’s perspective, validate security controls, identify attack paths, challenge assumptions, and prioritize remediation before those weaknesses are discovered by someone else.
Ultimately, the goal is not only to say that a penetration test was completed. It is to use the test to demonstrate that security controls are working, identify where they are not, and improve the security of the environment.
In addition to helping create Incident Response Plans, providing CISO Support, and Vulnerability Assessments… Alias also provides an array of Penetration Testing to help you find ways attackers might be able to disrupt the supply chain.
Need help? Contact us.
Supply Chain Attacks Explained for Engineers, CISOs, and the “Why Is This My Problem?” Executive Team If cybersecurity had a greatest-hits album, “trusted relationships abused” would be the platinum single ...
