PCI-DSS (Payment Card Industry Data Security Standard) is a widely recognized set of security standards designed to ensure the safety of payment card information. PCI-DSS v4 is the latest iteration of this standard, and it has introduced some significant changes to help combat the growing threats to payment card data. In this article, we will delve into the details of the new PCI-DSS v4 standard and what it means for businesses.
A Short History of the PCI DSS
As eCommerce grew in popularity during the DotCom era, so too did credit card fraud. In the early 21st century credit card companies began issuing security standards for their merchants and payment processors. To simplify compliance, in 2004 Visa, Mastercard, American Express, Discover, and JCB introduced the Payment Card Industry Data Security Standard (PCI DSS). Version 1 of the standard was designed to establish a common set of security requirements for all merchants and service providers that handle credit card information.
The initial versions of the DSS were brief while managing to cover the primary threats faced by organizations at that time. While the wording has changed a little, Version 1.1, introduced in 2006, covered the same six domains still used today. Logging in at just 17 pages (including cover pages and appendices) it helped organizations mitigate threats by deploying firewalls, encrypting data, and developing secure systems.
PCI DSS 4.0
In response to changing threats, in March 2022 the PCI Security Standards Council released PCI DSS v4.0. While the standard maintains the six domains and 12 requirements of the original versions, it now covers over 350 pages of guidance and prescriptive controls. Compared to version 3.2.1, PCI DSS 4.0 includes over 80 evolving requirements, including 60 new requirements. These range from encryption algorithms used to render PAN unreadable on removable electronic media to new requirements exclusively for service providers.
Given the vast changes in 4.0, the Council is allowing organizations and auditors time to prepare for compliance. Many of the new requirements are “future dated” and not required until March 31, 2025. In the meantime, they are considered “best practices’ ‘. Organizations are encouraged to implement these items but are not required to validate the controls. The timeline below from the PCI Security Standards Council provides further color.
Requirement 6: Develop and Maintain Secure Systems and Software
Just as the PCI DSS has changed to address emerging needs, so too have software development processes. Long gone are the days of quarterly releases and minimal security checks. Today’s development teams must meet faster release cycles with more stringent security requirements. The need for developer-centric security has never been greater. Something about changes to software development over the past years (faster release cycles/more focus on security/shift left)
For this reason we want to focus on the changes in Requirement 6 that pertain to building more secure software.
Requirement 6.1: Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
Beginning a security program requires organizations to establish policies and best practices. Requirement 6.1 is designed to track that and ensure that organizations develop, maintain, and follow secure coding practices for applications they develop and that these practices are integrated into the software development life cycle.
Requirement 6.1.2: Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
Effective Date: Immediate for all v4.0 assessments
6.1.2 is new. Similar language is also present in all requirements. Previous versions of the PCI DSS rarely required documenting which roles had day-to-day responsibility for each activity. It appears the Council has recognized that group accountability is insufficient in ensuring security and that PCI compliance must be part of an organization’s “business-as-usual” processes. It recommends auditors “Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 6 are documented and assigned.”
Requirement 6.3 Security vulnerabilities are identified and addressed.
The security efforts of many organizations focus on Requirement 6.3. The requirement is far reaching and is also referenced in across other Requirement 6 sub-requirements as well as Requirement 2.2 (System components are configured and managed securely), Requirement 11.3 (External and internal vulnerabilities are regularly identified, prioritized, and addressed), 11.4 (External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected), and others.
6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
Effective Date: March 31, 2025. Best practice until effective date.
Requirement 6.3.2 is a significant change to the DSS. It also is not a surprise to anyone who has been following application security in recent years. According to the 2023 Open Source Security and Risk Analysis report from Synopsys, open source comprises 76 percent of the average commercial application. 84 percent of those code bases included at least one vulnerability in open source components, and 48 percent contained high risk vulnerabilities.
Vulnerabilities in open source are particularly troublesome. Identifying zero-day vulnerabilities in custom applications is difficult. Publicly disclosed vulnerabilities in open source components can be repurposed easily by attackers to identify vulnerable systems. This threat gained a lot of attention after the Equifax breach in 2017. More recently, Executive Order 14028 requires organizations providing software to the US government to include a Software Bill of Materials, or SBOM. Many organizations recognized this threat years ago and began tracking the open source they use. PCI DSS 4.0 makes it a requirement.
6.4 Public-facing web applications are protected against attacks.
Publicly facing web applications are the perimeter for sensitive information. Adversaries have unfettered access to these applications, and coding errors, design flaws, or misconfigurations can provide easy access to sensitive data.
6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
• Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
• Actively running and up to date as applicable.
• Generating audit logs.
• Configured to either block web-based attacks or generate an alert that is immediately investigated.
Effective Date: March 31, 2025. Best practice until effective date
Requirement 6.4.2 is a reminder that – even in the most diligent development environments – residual risk can remain. An “automated technical solution” like a web application firewall (WAF) is designed to protect web applications from threats such as Denial of Service (DoS), SQL injections, and Cross-site scripting attacks.
An interesting aspect of the 6.4.2 is the requirement to “prevent” web-based attacks. Most organizations deploy WAF to generate alerts rather than block all suspicious activity, since the latter can also result in false positives that block legitimate traffic. One assumes that a WAF that prevents some attacks (through rate limiting to block brute force attacks) will meet auditors’ requirements.
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written justification as to why each is necessary.
Effective Date: March 31, 2025. Best practice until effective date.
Like Requirement 6.3.2, the Requirement necessitates visibility to potential threats, including the creation and ongoing management of an inventory of payment page scripts used in an application. The DSS suggests teams can meet this requirement through the use of SubResource integrity (SRI) and Content Security Policy (CSP) controls.
How SD Elements Helps
Version 4 of the PCI DSS introduces 60 new requirements with which development, security, and operations teams must comply. But it is just one of many regulatory requirements organizations must anticipate, understand, and validate their applications. Keeping controls current with rapidly changing and often overlapping requirements can challenge even the most well-staffed and funded organizations.
The key to compliance is visibility to requirements and consistency in approved security controls. Testing for compliance at the end of the development process slows down development and contributes to friction between development, compliance, and security teams. Teams can only maintain compliance while meeting aggressive product delivery goals by anticipating each requirement and assigning controls to appropriate team members prior to beginning development.
While many of the new requirements will not be enforced until 2025, smart organizations are preparing today. SD Elements provides teams with a simple method for complying with PCI DSS and scores of additional security and privacy guidelines. It includes developer-centric recommendations for how to satisfy PCI-DSS v4.0 requirements, including specific countermeasures and e-learning coursework.
Using SD Elements is simple. It starts with a short survey describing an application’s technical stack, deployment environment, and relevant regulatory guidelines. SD Elements translates these into a list of security requirements and actionable controls that are assigned to development, security, and operations personnel through their normal workflow. Making PCI DSS compliance part of your “business as usual” operation minimizes the chance of compliance violations and ensures developers are leveraging a secure, reliable source of information.
Ready to see what SD Elements can do? Book a demo!