Enabling Proper PCI Testing with External Penetration Tests

During my time as a consultant and a Qualified Security Assessor, I’ve had the privilege of assessing many organizations’ readiness to see if they meet the requirements of the Payment Card Industry’s Data Security Standard, known to most as PCI DSS.

Bishop Fox receives many questions from clients about the PCI DSS and if we can help them meet this industry standard utilizing our penetration testing services. The short answer is yes. The following Bishop Fox services help with meeting the PCI DSS penetration testing standards:

• Application Penetration Testing
• External Penetration Testing
• Internal Penetration Testing
• Cloud Penetration Testing

In this blog series, we will deep dive into each type of penetration testing listed above and explore how pen testing will help you meet not only the requirements within the PCI DSS, whether Self-Assessment Questionnaire (SAQ) and Report on Compliance (ROC), but also the non-mandatory guidance recommendations.

If you are interested in external penetration testing as it relates to the PCI DSS, this blog is a must-read resource for your organization.

The TL;DR on PCI DSS External Penetration Testing

Here is a high-level overview of external penetration testing recommendations to assist organizations with meeting compliance requirements.

• Test every internet-facing asset that the organization owns, including remote access vectors.
• Attacking systems must be allowed to access IP-restricted services.
• Social engineering attacks should provide a meaningful result for the organization.
• Perform allow-listing of attacker IP addresses so they aren’t impacted by intrusion prevention systems or web application firewalls.

This shortlist is based on a combination of PCI DSS requirements as well as the non-mandatory guidance recommendations. While it is not mandatory for organizations to be compliant with the guidance recommendations, this blog will demonstrate why adhering to both PCI DSS requirements and guidance is critical for your organization's security posture.

Compliance with standardized requirements is only one part of the puzzle for safer cardholder data environments (CDE); however, upgrading to include a wider pen testing scope is a worthy security investment that goes beyond basic PCI compliance.

External Penetration Testing

An external penetration test simulates the real-world tactics adversaries use to exploit an organization’s attack surface perimeter. The intent of this type of testing is to assess and measure an organization’s level of potential exposure to compromise.

At Bishop Fox, we ensure that our external penetration testing methodology not only includes Requirement 11.3.1, but also the guidance issued by the PCI Standards Security Council (PCI SSC). This guidance aims to further define the documentation within the requirements.

Let’s review portions of Requirement 11.3.1 and synthesize an approach that meets both the requirements and the guidance, with the intent to meet any Qualified Security Assessor’s expectations.

Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). - PCI DSS Requirement 11.3.1

So, with this, we know we must perform an external penetration test based on Requirement 11.3.1, but what exactly does that mean for organizations working with payment card data? Let’s refer to the Penetration Testing Guidance document for additional context and formulate a plan to maximize the effectiveness for the allotted time of an external penetration test for PCI DSS purposes.

The scope of an external penetration test is the exposed external perimeter of the CDE and critical systems connected or accessible to public network infrastructures. It should assess any unique access to the scope from the public networks, including services that have access restricted to individual external IP addresses. Testing must include both application-layer and network-layer assessments. External penetration tests also include remote access vectors such as dial-up and VPN connections. - External Penetration Testing Guidance Section 2.2.1

Great, so we are now on the right path. Thus far, we know that an external penetration test should include:

• Every internet-facing asset that the organization owns, including remote access vectors.

• Attacking systems that are permitted to access IP-restricted services.

Don’t Forget Social Engineering!

Let’s also consider this approach before putting together our final strategy.

Social engineering is the attempt to gain information, access, or introduce unauthorized software into the environment through the manipulation of end users. PCI DSS reconfirms testing by requiring industry accepted penetration-testing approaches (many of which include social engineering as part of their approach) and to have an approach to penetration testing that considers the threats and vulnerabilities experienced by merchants in the last 12 months. This may include social-engineering attacks as a method used for introducing malware into the environment…

These tests might include in-person, non-technological interactions such as persuading someone to hold open a door, remote interactions such as having someone provide or reset a password, or convincing the end user to open a vulnerable e-mail attachment or hyperlink…

While PCI DSS does not require testing to include social-engineering techniques, an entity can incorporate it into its penetration testing methodology as an ongoing method to determine the effectiveness of the security awareness program….

Social-engineering testing may not be appropriate or provide a meaningful result for all organizations. Although social-engineering testing is not a requirement of PCI DSS, an organization may consider documenting the reason(s) for foregoing social-engineering testing and include applicable documentation with the internal and external penetration test reports, particularly if social-engineering attacks were encountered in the last 12 months. - Social Engineering Guidance Section 2.5

Alright, that was quite a bit of information, but the key takeaway from our perspective is that organizations should aim to include social engineering attacks in their penetration tests.

According to the Risk and Vulnerability Assessment (RVA) issued by the Cybersecurity and Infrastructure Security Agency (CISA), 54.3% of threat actors gain initial access via preowned, valid accounts shared in the darker parts of the internet. Additionally, 33.8% of initial access obtained by threat actors was derived from spear phishing links.

Incorporating tactics like credential harvesting and linked attachments in spear phishing campaigns will give an organization a chance to see how they stack up to real-life attacks. It also represents an accurate depiction of today’s threat landscape.

Great, so let’s add an additional factor to our penetration testing assessment:

• Perform social engineering attacks that provide a meaningful result for the organization.

Lastly, before we put our final approach together, we need to consider the guidance’s comments on avoiding scan interference.

In many environments, active protection controls, such as an intrusion prevention system, or web active protection systems, such as intrusion protection systems (IPS) and web application firewalls (WAF), may be deployed to protect exposed services. Because the intent of the penetration test is to evaluate the services’ susceptibility to exploitation (vs. the active protection systems’ ability to prevent attacks), interference with the penetration test should be avoided—entities are encouraged to review and be familiar with the section titled “Scan Interference” in the ASV Program Guide and configure active-protection systems accordingly during testing. Avoid scan interference on security appliances. - Section 4.1.7

This section is quite clear, “…because the intent of the penetration test is to evaluate the services’ susceptibility to exploitation, interference with the penetration test should be avoided…”

Let’s add that to our list of penetration testing assessment requirements.

• Perform allow-listing of attacker IP addresses so they are not impacted by intrusion prevention systems or web application firewalls.

To recap, here is the list of best practices to incorporate in your penetration testing assessment:

• Every internet-facing asset that the organization owns, including remote access vectors.

• Attacking systems that are permitted to access IP-restricted services.

• Perform social engineering attacks that provide a meaningful result for the organization.

• Perform allow-listing of attacker IP addresses so they are not impacted by intrusion prevention systems or web application firewalls.

PCI DSS Case Studies

One of the consequences we’ve seen in terms of the commodification of penetration assessment work is a reduction in scope for penetration tests.

Most often, external penetration tests have turned into myopic security assessments that disregard the interconnectedness of systems. This tends to be a result of downward pressures from organizational security budgets, doing the bare minimum to meet the compliance requirements, and, in some cases, performance incentives related to a lack of security findings.

We’ll further explore this idea in two subsequent case studies based on my experience as a consultant over the past decade.

• One is based on an organization that was concerned primarily with meeting compliance objectives, with security as a secondary concern.
• The second case study is based on an organization that worked collaboratively with the penetration testers, adopted a wide testing scope, and valued the ROI of using real-life adversarial tactics, techniques, and procedures during the engagement to test the external perimeter.

Myopic External Penetration Test

The Scope

This organization needed to perform an external penetration assessment for PCI DSS, and they were only concerned with meeting the requirement. The external penetration scope included seven payment proxy servers, all with mutual TLS (mTLS).

While the client did have other assets, they did not consider them as part of the scope for the PCI DSS pen test. The following assets that were not permitted within the testing scope included: the website that was hosted within the organization’s DMZ, the remote access Citrix and VPN portals, and the numerous software-as-a-service (SaaS) vendors that the client used.

The external penetration test was performed, and mTLS was confirmed because we were unable to communicate with the application services without a valid certificate. No network or web server vulnerabilities existed.

The Reality

The client was later compromised through a vendor that had a valid certificate to interact with their services. The external penetration assessment met the requirements yet did not meet the guidance. If the penetration testers had been provided with a valid mTLS certificate (simulating the risk inherent in providing access to third-party vendors), they could have discovered the textbook SQL injection vulnerability that was later exploited by attackers. In essence, the organization paid for a false sense of security because they followed the requirements without the accompanying guidance.

Compromise by Proxy

The Scope

An organization needed to perform an external penetration assessment for PCI DSS, and they were concerned with modeling what real threats were doing to their attack surface while concurrently meeting the compliance requirements of the assessment. To this end, the following scope was provided for testing external-facing assets:

• All external assets facing the internet, including Office365 and other SaaS applications were to be used as intended and not attacked directly.

• Attacking systems were allow-listed to services typically restricted by IP address, with the understanding that the allowances would be detailed along with the threat models within the report. For example, compromise through a vendor that was allow-listed to the organization’s APIs would be included in the requirements for exploitation.

• Social engineering was in-scope but required approval for intended approach, potential targets, and the overall goal of the campaign.

• Attacking systems were allow-listed in web application firewalls and intrusion prevention systems.

These are the types of engagements the consultants at Bishop Fox get particularly excited to work on because we get to emulate real threat actors and mimic how an adversary would maneuver to achieve the goals of the assessment. In other words, we get that sweet, sweet cardholder data or confirm it is appropriately secured in the time we have. 

The Reality

Due to the wide scope and indifference about detection, there was the opportunity to create novel attack chains that provided a high level of value to the organization. Here’s the attack chain that we developed:

• We phished credentials via a credential harvesting link and web application that appeared to be a corporate portal.

• While VPN and Citrix had multi-factor authentication, the Single Sign-On (SSO) portal did not and was running an application that managed the organization’s help desk tickets.

• The ticket application was accessible, and a malicious PowerPoint was created that executed a stage 0 malware when elements in the PowerPoint were triggered by the mouse.

• We created a help desk ticket from the Information Security department related to broken security awareness training materials since the malicious PowerPoint intentionally “crashed” after multiple payload executions.

• Help desk users interacted with the malicious PowerPoint, and internal network access was obtained.

• The helpdesk user had a local administrator password in a note on their desktop that was retrieved via the malware taking screenshots of the user’s desktop.

• Lateral movement was performed, and CDE access was eventually obtained through this proxy.

In this scenario we have an example of what effective penetration testing should be, but we also identify other useful tactics, techniques, and procedures that may be impactful for improving the client's security posture and obtaining access to the CDE. 

Closing Thoughts

For organizations to not only meet compliance objectives, but ensure that real value is extracted from a security assessment (which is allowed to model the threat landscape of today), three things must occur:

• A nuanced understanding of what the PCI DSS is attempting to address
• Establishment of one’s organizational risk appetite
• The goals of security work refuse to acquiesce to the pressures of commodification

Did we miss anything? Any considerations from the community on things you do when performing this type of work to ensure the deliverable passes any QSA’s muster?

Stay tuned for the next part of the series that will focus on internal penetration and segmentation testing! 

Helpful Resources

• PCI DSS Document Library
• PCI DSS Penetration Testing Guidance

• PCI DSS v3.2 Report on Compliance

• PCI DSS v4.0 Report on Compliance

• PCI DSS v3.2.1 to v4.0 Summary of Changes

• Cybersecurity and Infrastructure Agency (CISA) Risk and Vulnerability Assessment Results