Before the Payment Card Industry Data Security Standard (PCI DSS) was created around 2004, consumers and merchants alike were plagued by many fragmented payment systems. It was a constant headache and source of risk – especially when one credit card company’s policies violated another’s, mandated different security controls, or simply weren’t following guidelines as thoroughly as they should have been. When the PCI Security Standards Council (PCI SSC) fully formed and released compliance guidelines for the industry, merchants of all sizes finally had a common baseline for protecting payment account data throughout the payment lifecycle while enabling more secure technology solutions. 

The original PCI DSS v1.0 was released in 2004 and has seen several major overhauls, with v3.2.1 being the current active version. In 2022, nearly 20 years since the first release, v4.0 was published in an effort to keep pace with rapid advances in technology and dynamic changes to the security landscape. The latest update brings fresh cybersecurity guidelines for organizations that need to secure their web apps and protect payment card data.

PCI DSS changes include tighter protocols for securing web apps

Version 4 of the PCI Data Security Standard includes a stricter approach to web application security in order to achieve PCI compliance, no matter the size of an organization. There were quite a few changes made between v3.2.1 and v4.0 to restructure the standard and bring it into line with the current security realities of payment processing ecosystems. Alongside more general requirements for anti-phishing and anti-malware measures as well as network security, several new or updated guidelines are related specifically to application security:

• Implement multi-factor authentication (MFA) throughout the common data environment
• Don’t hard-code passwords used in applications and systems accounts
• Use automated technical solutions for detecting and preventing web-based attacks, such as web application firewalls (WAFs)
• Perform authenticated vulnerability scanning
• Prevent common application vulnerabilities by using suitable methods and tools already during development (aka shifting left)
• Run external and internal vulnerability scans at least once every three months and after every significant change

Of note is requirement 6.4.2, which becomes mandatory in March 2025 and requires organizations to “deploy an automated technical solution for public-facing web applications.” Once in force, it will replace the option provided in requirement 6.4.1 to only perform periodic manual web application reviews without automated measures. The change should encourage organizations to begin the process of understanding their risk and implementing automated tools to reduce it in a continuous process. 

Several requirements either list or imply the need for dynamic vulnerability scanning. In the examples of vulnerabilities to be prevented or mitigated already during development, requirement 6.2.4 lists a number of security flaws that are typically identified using dynamic testing. This includes all types of injection vulnerabilities (notably SQL injection and command injection), client-side vulnerabilities like cross-site scripting (XSS) and cross-site request forgery (CSRF), insecure API access, and security misconfigurations. What’s more, all of section 11.3 is devoted to internal and external vulnerability scans. Requirements include scanning both periodically and after every significant change, resolving all high and critical vulnerabilities, and rescanning all fixes to ensure they are effective.

Another important update is requirement 6.3.2, which also takes full effect in March 2025 and covers patch management. In this requirement for bespoke and custom software, organizations must maintain an inventory of their assets so they know the full extent of their attack surface. In practice, this could be achieved through asset discovery and management, by running software composition analysis (SCA), and by maintaining software bills of materials (SBOMs) for all applications.

How to prepare your web security program for PCI DSS compliance 

Paying lip service to compliance requirements is never a good idea, especially when it comes to security. Doing only the bare minimum needed for security certification can create a false sense of security and put the entire organization at risk. For payment processors in particular, a comprehensive security strategy that takes compliance requirements as its baseline is the best way to reduce the risk of security incidents and breaches when handling sensitive financial data and transactions.

Here are five best practices for covering web application security as part of your PCI DSS compliance efforts:   

• Build security into application and process design and architecture. This includes following secure design and coding practices, running and maintaining runtime protection measures such as WAFs, keeping up with security updates, and embedding application security testing into the development process by shifting left. 
• Make accurate vulnerability scanning a continuous process within operations and development. Apart from being explicitly mandated in the new PCI DSS version, vulnerability scans can do double duty, minimizing your current attack exposure on the one hand and preventing new vulnerabilities from being implemented on the other.
• Keep a handle on access control to protect data across your web apps and APIs. Proper access control to back-end systems and front-end applications is a must for any organization that processes sensitive cardholder data, but with the vast majority of data operations now performed via APIs, you also need to ensure (and then test) that your API endpoints also enforce correct authentication and authorization. 
• Ensure your vulnerability management covers both publicly reported issues (CVEs) and flaws in your custom code. PCI DSS v4.0 specifically mandates that while you need to keep up with external vulnerability reports and ensure your scans incorporate them, you also need to minimize vulnerabilities in new or customized software, in practice requiring you to both scan for vulnerable components and test for security weaknesses. 
• Automate security testing as far as possible to maximize efficiency. The updated standard requires the use of automated security tools alongside any manual reviews and tests, so it is crucial to minimize the noise generated by any automated scanners in your toolset. Features like automatic vulnerability verification can help your teams focus on actionable issues without distractions and false alarms. 

Following these best practices for securing your web apps and software should have your organization in good shape to prepare for formal certification for any PCI DSS version. For specific requirements, keep in mind that there is a strict implementation timeline for moving to v4.0:

Source: https://blog.pcisecuritystandards.org/countdown-to-pci-dss-v4.0

As of this writing, we are still in a transition period where v3.2.1 is active, and v4.0 is only recommended. As we move closer to the deadlines in March of 2024 and then 2025 (for the full set of requirements), integrating best practices and more modern tooling into your software development lifecycle today will lay the foundation for a successful compliance process tomorrow.  

How Invicti can help with PCI DSS compliance

Invicti provides out-of-the-box scan profiles and reports for web vulnerabilities covered by PCI Data Security Standard requirements. We also work with a third-party ASV (Approved Scanning Vendor) to provide one-click PCI DSS compliance confirmation for web applications. To learn how Invicti can be your partner in achieving and maintaining PCI DSS compliance, contact our sales team.

Frequently asked questions