Version 4.0 of the Payment Card Industry Data Security Standard (PCI DSS) puts greater emphasis on application security than did previous versions of the standard. It also adds a new "customized approach" option that allows merchants and other entities to come up with their own ways to comply with requirements, and which also has implications for application security.
Specifically, PCI DSS 4.0, which is rolling out in two phases on March 31, 2024, and March 31, 2025, requires more testing of public-facing applications related to payment processing or other activities considered "in scope" for compliance.
Generally, any system that touches payment-card data is in scope for PCI DSS compliance, whether or not the system or function is public-facing.
More tools, more documentation in PCI-compliant AppSec
Most of the requirements governing application security fall into Section 6 of PCI DSS 4.0, with three new requirements, all of which go into effect in 2025, standing out.
Requirement 6.3.2 says that entities must keep "an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software" to make patching and vulnerability management easier. It's essentially an order to keep a software bill of materials (SBOM) for software that was developed or modified in-house.
Requirement 6.4.2 mandates the use of an automated tool that "continually detects and prevents" web-based attacks on web applications. This replaces an older requirement that web apps needed only vulnerability scans.
As an example of an automated tool that would fit the bill, the requirement gives a web application firewall (WAF), although it doesn't specify that a WAF must be used. It also mentions rate-limiting controls "to mitigate against brute-force attacks and enumeration attacks" as another example.
What truly matters is that "public-facing web applications are protected in real time against malicious attacks," as states the objective for the customized approach to the requirement.
Requirement 6.4.3 says online retail websites must manage, verify and inventory all scripts running on payment pages, and prevent unauthorized code or scripts from running on those pages.
And more testing
Taken together, these requirements spell out that payment pages and web applications must be verified and penetration tested.
Another requirement, 11.4.4, says that every single vulnerability found in a pen test must be remediated, no matter how small, and a second pen test performed to verify the fixes. Requirement 11.6.1, new with PCI DSS 4.0, says entities must implement a manual or automated "mechanism" to check payment-page content and HTTP headers weekly for evidence of tampering and other unauthorized changes.
"Penetration testers can use tools like BurpSuite to manipulate requests to payment pages in an attempt to inject malicious code, " says Scott Goodwin, Principal, Cybersecurity and Privacy Advisory, PKF O'Connor Davies LLP.
To prevent vulnerabilities and other errors from being deployed, developers will have to continually test in-scope applications during the software development life cycle (SDLC) using static application security testing (SAST) and dynamic application security testing (DAST) tools.
That's implied in Requirement 6.2.1, which mandates that "bespoke and custom software are developed securely" and "incorporat[e] consideration of information security issues during each stage of the software development lifecycle."
However, it's explicit in requirement 6.2.3, which clearly states that code reviews must be carried out on "bespoke or custom" software "prior to being released into production or to customers."
Likewise, the application-program interfaces (APIs) that connect various applications and systems within the payment-processing system must also be scanned for vulnerabilities and penetration-tested.
The optimal testing framework for both web apps and APIs is the Open Worldwide (formerly Open Web) Application Security Project (OWASP) "Top Ten" list of application-security risks, which PCI DSS 4.0 cites several times as a reference model.
"Before, APIs were kind of the secure thing that no one can compromise," says Clone Systems Senior Security Engineer Tom 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."
More scrutiny for application security
Developers, like penetration testers, come under greater scrutiny with PCI DSS 4.0 than they did in previous versions of the standard.
As with PCI DSS 3.2.1, developers must get refresher training in secure coding every year, but version 4.0 adds a requirement (6.2.2.b) that the developers must be interviewed to verify that they received the training.
It also requires (6.1.2.b) that developers (and other personnel involved in "developing and maintaining secure systems") be interviewed to verify that their "roles and responsibilities" in creating secure software are understood and properly documented.
A RACI (responsibility, accountability, consultation, and information) matrix is given as an example of an acceptable framework. This requirement goes into effect in 2024, a year earlier than most other PCI DSS 4.0 requirements.
Entities must thus decide who on their teams plays which role in developing and maintaining secure software and must document and assign those roles in a way that can be presented to PCI-certified Qualified Security Assessors (QSA) — all before March 31, 2024.
Customized approaches
As mentioned earlier, customized approaches are an option for entities that have mature security teams and can implement their own methods of satisfying individual PCI DSS 4.0 requirements instead of sticking to the "defined approaches" spelled out in the requirements.
Every customized approach must be subjected to a targeted risk assessment by the entity developing it and must also be examined and approved by a QSA to verify that it complies with PCI DSS.
Any company seeking to use the customized approach may be creating more work for its security and development teams. But it may also lessen the workload, as large organizations that must comply with many different rules and regulations can use the customized approach to "borrow" controls from other frameworks to satisfy individual PCI DSS 4.0 requirements.
"Compliance shouldn't be a burden if you're already doing what you should be doing," says Meghan Maneval, Vice President of Product Strategy and Evangelism at RiskOptics. "If you're already compliant with other regulations, then complying with PCI shouldn't be that hard."
