What PCI DSS 4.0 means for pen testers

On the positive side, the updated standard may mean better business for pen testers. PCI DSS 4.0 widens the scope of PCI pen tests, allows pen testers more leeway in how tests are conducted and explicitly requires that follow-up pen tests be conducted to verify that vulnerabilities have been remediated.

The overall framework of penetration testing for PCI DSS compliance stays mostly the same. PCI pen testing should take at least three approaches: an external black-box test, an internal test in which the pen tester tries to get into the cardholder data environment (CDE) from other parts of the network, and an internal test from inside the CDE itself.

Required PCI pen testing is still just once a year for most merchants, and twice yearly for service providers. More frequent pen tests are required if there is a security incident or, as the PCI DSS requirements and testing procedures state, “any significant infrastructure or application upgrade or change.”

But PCI DSS 4.0 introduces stricter requirements to verify the safety of online payment pages and web-based applications. It also adds an explicit requirement that cloud service providers give pen testers access to their clients’ cloud assets. We’ll go over both those details, plus requirements about documentation and retention of records, below.

The most significant innovation in PCI DSS 4.0 is the ability for entities — i.e., any organization that must comply with PCI DSS — to choose “customized approaches” for individual requirements.

Customized approaches may seem like an expansion of the “compensating controls” loophole that previous versions of PCI DSS offered if a company couldn’t quite meet the exact details of a particular requirement for technical reasons.

Compensating controls still exist in PCI DSS 4.0, but customized approaches are optional and offer something much better: A way for organizations, if capable, to meet individual PCI DSS requirements on their own terms rather than by sticking to the prescribed “defined approach.” This is ideal for companies that have complex architectures or that must comply with many different regulatory frameworks.

“Unlike compensating controls, which are used when organizations have a constraint and are unable to meet the requirement as stated, the customized approach is for entities that choose to meet the requirement differently than is stated,” explained Lauren Holloway of the PCI Security Standards Council in an official blog post.

A customized approach gives pen testers more flexibility in how to conduct a pen test on a particular requirement as long as everything about the customized approach, and the test, is documented down to the smallest detail.

Because PCI DSS 4.0 requires that each planned customized approach be subjected to a targeted risk analysis by March 31, 2024, it’s possible that pen testers may be asked to conduct or assist with that process in the next few months.

PCI DSS adds new requirements covering payment pages and web apps. Requirement 6.4.2, which goes into effect in 2025, mandates the use of an automated tool to detect and prevent attacks on web applications.

This replaces an older requirement (6.6 in PCI DSS 3.2.1, 6.4.1 as a one-year temporary option in PCI DSS 4.0) that web apps merely get vulnerability scans. By implication, web apps now need to be actively pen-tested.

According to Clone Systems Senior Security Engineer Tom Nianios, this puts application-program interfaces (APIs) into the scope of PCI compliance pen tests. He suggests using the Open Worldwide Application Security Project (OWASP) Top Ten framework as a guide.

“Before, APIs were kind of the secure thing that no one can compromise,” says Nianios. “But now, APIs are within scope. So you need to test the web-application API, and you need to test the web application, obviously, with the OWASP standard.”

There’s also a brand-new requirement, 6.4.3, mandating all organizations that maintain online payment pages to manage, verify and inventory all scripts running on those pages, and to block unauthorized code or scripts.

Another new requirement (11.6.1) says that entities must implement a “mechanism,” either manual or automated, to check payment-page content and HTTP headers at least weekly for evidence of tampering and unauthorized changes.

Scott Goodwin, a principal in the cybersecurity and privacy advisory at consulting firm PKF O’Connor Davies LLP, suggests that pen testers try to manipulate payment pages directly.

“Penetration testers can use tools like BurpSuite to manipulate requests to payment pages in an attempt to inject malicious code,” he says, “and tools like SQLMap and SMBMap to identify and manipulate data stored in databases and on file shares, respectively.”

PCI DSS 4.0 puts greater emphasis on network segmentation. It clarifies in requirement 11.4.5 (replacing requirement 11.3.4 in PCI DSS 3.2.1) that annual pen tests be conducted “according to the entity’s defined penetration-testing methodology” to, as before, confirm that the segmentation works properly to isolate “all out-of-scope systems” from the CDE. PCI DSS was less stringent in this respect, asking only that pen testers verify segmentation as part of their testing procedures.

The requirement adds a new spin: Segmentation pen-testing must also confirm the isolation of “systems with differing security levels,” an aspect not present in PCI DSS 3.2.1.

That in turn references requirement 2.2.3, which mandates that “primary functions with differing security levels that exist on the same system component are isolated from each other” or “are all secured to the level required by the function with the highest security need.”

This is a bit looser than PCI DSS 3.2.1 requirement 2.2.1, which mandates that primary functions with different security levels should not be on the same server at all. PCI DSS 4.0 retains that as an option but not an absolute requirement, perhaps showing a bit more faith in the ability of segmentation to properly separate components.

Cloud assets, including web apps, and cloud-based virtual servers have always been within the scope of PCI pen tests if they held or touched the CDE. But PCI DSS 4.0 should make it easier to access those assets if they’re on “public” clouds run by the likes of Amazon Web Services, Microsoft Azure or Google Cloud Platform.

The new requirement 11.4.7 states that “multi-tenant service providers” — which includes cloud service providers (CSPs) — must “support their customers for external penetration testing.” The multi-tenant service providers must also either show their clients documentation that a pen test has been done, or let their clients perform their own pen tests.

This was likely added because historically, some CSPs haven’t liked third-party pen testers poking around in their systems. PCI DSS 4.0 removes any doubt that CSP customers have a right to get someone to pen-test their own assets in someone else’s cloud.

There are strings attached, however. Cloud systems are obviously very different from on-prem systems, even those running virtual servers, and learning to navigate them may require additional training.

“[The cloud] is a new set of skills. And it is a new set of methodologies,” says Nianios. “However, it’s easier [to pen test], in my opinion, because all the security controls that they had in place on-site, all these layers that they’ve added over the years, they don’t exist over there [in the cloud].”

Pen-testing a third party’s cloud assets could cause legal trouble, too. Before a pen-testing firm goes into a client’s assets on a third-party public cloud, it needs to thoroughly understand the specific shared-responsibility agreement between the client and the CSP (perhaps better than the client does), and to establish exactly where the red lines marking the beginnings of CSP responsibility are.

Pen testers “really need to dig into the licensing and contractual agreements that that organization would have with the cloud provider,” explains Jason Stockinger, Director of Global Information Security at Royal Caribbean Group. “For example, if you’re doing infrastructure as a service, [the cloud provider] is not going to allow you to pen-test past a certain point. If you start probing that, it’ll be a breach of contract.”

PCI DSS 4.0 requirement 11.4.1 is an update of PCI DSS 3.2.1 requirement 11.3 and clarifies that the complying entity must define, document and implement a pen-testing methodology. It’s a bit less stringent in that it lets the entity figure out the methodology.

That methodology doesn’t have to be a cookie-cutter version of a standard pen-testing frameworks like OWASP or the Open-Source Security Testing Methodology Manual (OSSTMM) — many pen testers mix and match parts from different methodologies — but it has to be documented and defined.

The means of pen-testing the network inside and out also needs to be documented and clarifies that the various attack vectors and vulnerabilities defined in requirements 6.2.4 and 6.3.1 must be addressed.

Pen testers will have to show that they tried to get in via “injection attacks, including SQL, LDAP, XPath” and attacks on “data and data structures”, “cryptography usage,” “business logic,” “access control mechanisms” and so on, and that commonly known vulnerabilities are also addressed.

Requirement 11.4.4 clarifies that every vulnerability documented in the final pen-test report must be remediated, no matter how small. The means of remediation must be documented, and then a second pen test must be performed to verify those remediations. Previously, PCI DSS 3.2.1 required only that “testing is repeated to verify the corrections.”

Requirement 11.4.2b and 11.4.3b are the least fun parts. They add to their PCI DSS 3.2.1 predecessors (11.3.1b and 11.3.2b) by mandating that the complying entity not only verify that a “qualified internal resource or qualified external third party” carries out the pen test, but that the entity must also interview involved personnel as part of the verification process. Likewise, requirement 11.4.5c (replacing 11.3.4c) specifies that segmentation pen-testers be interviewed.

In other words, third-party pen testers may have to sit down and be grilled about how they conducted the tests, how they got into systems, what they found, and so forth.

The requirement is vague enough so that a detailed pen-test report presented an in-person meeting with the client may qualify as an “interview” as long as the client asks questions, but it might be best to bring along some of the front-line pen-testers just in case. It definitely means that pen testers will need to document every step of the pen-testing process if they’re not doing so already.

For the post-test period, PCI DSS 4.0 states in a bullet point in requirement 11.4.1 that all notes, records and reports from a PCI compliance pen test must be retained for at least 12 months. The length of the retention period wasn’t specified in PCI DSS 3.2.1.

The requirement doesn’t say whether the pen tester or the entity should be the one holding on to the records, but if they don’t have them already, firms that carry out PCI compliance pen tests may need to build secure storage systems that can easily retrieve such documents upon demand.

Finally, a social-engineering pen test is still not part of the PCI DSS requirements, but it may be more important than ever — especially when it comes to staffers who have privileged or administrative access to the CDE.

In well-defended organizations, such employees may be a weaker point of defense than the CDE itself. But pen-testing firms might have trouble getting their clients to pay for a social-engineering pen test until the PCI SSC makes it mandatory.

“While PCI DSS 4.0 does not explicitly require social engineering as a component of penetration tests, it is still one of the most common ways organizations are initially breached,” says Goodwin. “From a purely risk-based perspective, it makes sense for any organization processing cardholder data to engage in periodic adversarial social-engineering exercises.”

Paul Wagenseil is custom content strategist for CyberRisk Alliance, leading creation of content developed from CRA research and aligned to the most critical topics of interest for the cybersecurity community. He previously held editor roles focused on the security market at Tom’s Guide, Laptop Magazine, TechNewsDaily.com and SecurityNewsDaily.com.

The fileless, self-modifying, worm-like network traversal tool automatically searches for SSH keys.

Major crowdsourced cybersecurity platform Bugcrowd has landed $102 million from a new funding round, bringing total investment to more than $180 million, reports TechCrunch.

SiliconAngle reports that cybersecurity firm Trustwave has entered a deal to be acquired by The Chertoff Group’s affiliate growth equity fund MC2 Security Fund, the terms of which were not disclosed.

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.

Your use of this website constitutes acceptance of CyberRisk Alliance Privacy Policy and Terms & Conditions.