PCI DSS 4.0 and Client-Side Security: Changes & Impacts
PCI DSS is the “gold standard” for financial organizations and retailers in how they manage and protect sensitive credit card holder data. And organizations are definitely going to feel the impact of the shift to PCI DSS 4.0 on multiple levels. Read about the client-side PCI DSS 4.0 impacts and why it is so important for businesses to get started now as they prepare for PCI DSS 4.0.
What is PCI DSS v4.0?
The Payment Card Industry Standards Security Council (PCI SSC) released the newest version of the Payment Card Industry Data Security Standards (PCI DSS) v4.0 in March 2022, as part of their efforts to protect and secure credit card data and to reduce the number and impact of data breaches. According to PCI SCC, the new 4.0 requirements serve as “the global standard that provides a baseline of technical and operational requirements designated to protect payment data.”
When does PCI DSS 4.0 take effect?
The PCI SSC will retire PCI DSS 3.2.1 in March 2024. The new data security standards will go into effect 31 March 2025. To provide organizations time to understand and implement the changes in version 4.0 and for assessors to complete training, according to PCI SCC, between March 2024 and March 2025, organizations may assess either PCI DSS v4.0 or PCI DSS v3.2.1.
What do companies need to do to prepare for PCI DSS 4.0?
The biggest thing is to start now! PCI 4.0 expands existing requirements and includes brand new requirements that address changes to compliance, technologies, and an evolving threat landscape.
Because these expanded and new requirements will take time to establish and implement, the shift from 3.2.1 to 4.0 requires planning and early implementation of best practices. For example, Requirement 6 requires entities to maintain inventories of bespoke and custom software, deploy automated technical solutions for public facing web applications, and securely manage all payment page scripts loaded and executed in a customer’s browser. For mid-size to larger businesses with thousands of scripts operating on the client side, you’ll need to start preparing now for how you intend to inventory and securely manage those scripts—and demonstrate this through your assessments to your Qualified Security Assessors (QSAs).
What are the impacts of PCI 4.0 on client-side security?
First, it is important to note that PCI 4.0 impacts won’t just be felt when the new standards go into effect in 2025. To achieve PCI DSS compliance, planning and process implementation—such as identifying all web assets, their sources, and reviewing code—needs to happen prior. If an organization has client-side web applications that contain thousands of lines of code, then the code review process is going to take some time, unless it’s automated.
PCI 4.0 also places more emphasis on risk analysis and organizational governance thereby expanding the compliance scope. Compliance activities are no longer limited to once annually, but are now required continuously. Organizations will also be required to produce more security documentation. And regular QSA assessments will place PCI 4.0 activities under added scrutiny.
Requirements with notable impacts for the client side include:
Requirement 6
Requirement 6 has the biggest implications for client-side security and contains several updates to requirements as well as brand new requirements related to how businesses identify, inventory, and manage scripts operating in web browsers that collect payment information.
- A new key requirement—6.3.2—specifies that in order for organizations to manage vulnerabilities and patches, they are now required to identify and list all of their bespoke and custom software, and any third-party software that has been incorporated into the organization’s bespoke and custom software. The inventory should cover all “payment software components and dependencies, including supported execution platforms or environments, third-party libraries, services, and other required functionalities.”
- Requirement 6.3.3 calls for all system components to be protected from known vulnerabilities through the installation of applicable security patches and updates.
- Requirement 6.4.1 notes that for public-facing web applications, “new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected from known attacks.”
- Requirement 6.4.2 clarifies that automated public-facing web applications are configured correctly to detect and prevent web-based attacks, are actively running, are up to date, and are configured to block attacks or generate alerts indicating a potential issue that is immediately investigated.
- Requirement 6.4.3 specifies that any scripts that are loaded and executed in a customer’s browser be authorized. In addition, an inventory of scripts must be maintained with written justification as to why each script is necessary and a method must be implemented to assure the integrity of each script.
Requirement 11
There are three notable areas in Requirement 11 that impact client-side security:
- Requirement 11.3 specifies that businesses need to regularly identify, prioritize, and address external and internal vulnerabilities.
- Requirement 11.5 notes that businesses must detect and respond to network intrusions and unexpected file changes.
- Requirement 11.6 calls for businesses to detect and respond to unauthorized changes on payment pages.
Requirements 12 and 13
Requirements 12 and 13 expand the compliance scope and make compliance continuous, instead of just single snapshots in time. They also require merchants and service providers to conduct, at minimum, annual reviews of hardware and software technologies in use, including plans for remediation for outdated technologies.
What is the customized approach in PCI 4.0 and how does it impact the client side?
There are essentially two approaches in PCI DSS 4.0—a traditional approach and a customized approach. The customized approach includes “compensating controls” which enables organizations to adopt and follow custom controls based on individual PCI DSS requirements.
Previously in PCI v3.2.1, organizations that could not meet controls were allowed to provide alternatives and then justify those alternatives with a risk assessment and a detailed compensating control worksheet (CCW). PCI DSS 4.0 has changed this. While organizations can still do a risk assessment and provide a CCW, now organizations may opt to provide a customized control approach. The customized approach still requires a risk evaluation, but offers more flexibility when it comes to complying with PCI DSS.
In terms of client-side impacts, the compensating control component will enable businesses to build systems, processes, and controls that address the changing client-side threat landscape and evolving technologies. It also creates longer-term security controls, rather than short-term compensating controls.
Who is PCI DSS 4.0 for?
If you store, process, or transmit cardholder data (CHD), then you must comply with PCI DSS. While this obviously impacts retail—both online and bricks-and-mortar stores—it also has implications for other entities that accept payments online or in person, including healthcare organizations, financial services, digital entertainment and media entities, the hospitality and travel sector, and even cryptocurrency exchanges that facilitate crypto purchases via credit cards.
According to the PCI Security Standards Council: “PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). This includes all entities involved in payment card account processing —including merchants, processors, acquirers, issuers, and other service providers.
Who must comply with PCI DSS 4.0?
The answer to this is pretty simple: PCI DSS requirements apply to any organization with an environment where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted.
In addition, the PCI council also notes that there are organizations that may not store, process, or transmit account data, but whose environments can impact the security of the CDE. These might include entities that outsource payment operations or management of their cardholder data environment. Furthermore, even if an organization outsources their payment environment or payment operations to a third party, the organization is still responsible for securing and protecting account information.
PCI-DSS v4.0 vs. PCI-DSS v3.2.1: Why the change?
It’s been nine years since the last PCI DSS major overhaul so a change was long overdue. In the last few years, innovations in technology, the increasing use of cloud platforms, and evolving threat actor tactics, techniques, and procedures (TTPs), not to mention the impact of the global pandemic, have changed so much about the way both consumers and companies do business. Recognizing the need to update PCI DSS, the Council began laying the foundation for PCI DSS 4.0 in 2019, with its final release coming in Q1 2022, based on feedback from more than 200 organizations.
What is the cardholder data environment (CDE)?
According to PCI DSS, the cardholder data environment (CDE) consists of:
- System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data.
- System components that may not store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD) but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD.
- System components, people, and processes that could impact the security of the CDE.
PCI SSC defines system components as any network device, server, computing device, virtual components, cloud components, and software. This means that client-side websites and web applications are affected by PCI DSS compliance.
Why is client-side PCI DSS 4.0 so important to overall security?
Payment data is extremely vulnerable to attack, particularly on the client side. For this reason, and due to increasing client-side attacks, PCI DSS 4.0 specifically includes revisions and guidance on client-side security concerns around vulnerable payment data.
One of the biggest issues with client-side security is JavaScript. An estimated 98% of web applications use JavaScript. Unfortunately, JavaScript wasn’t designed with security in mind, making it ripe for vulnerabilities, manipulation, and attacks.
In addition, many organizations are relying on outdated solutions that don’t provide automation or the levels of protection needed for the client-side attack surface. Traditional solutions like web application firewalls (WAFs) don’t protect against supply chain attacks, sophisticated skimming malware, drive-by skimming, or sideloading and chainloading attacks. Content security policies (CSPs) that lack automation may present problems with misconfigurations, bypass techniques, and consistent policy application.
What are the best practices for PCI DSS 4.0 & Client-Side Security?
Start client-side PCI DSS 4.0 efforts now
PCI 4.0 expands existing requirements and includes brand new requirements. Because these expanded and new requirements will take time to establish and implement, the shift from 3.2.1 to 4.0 requires planning and early implementation of best practices.
Automate solutions that support PCI 4.0
Documenting and maintaining inventories of bespoke and custom software in order to securely manage all payment page scripts loaded and executed in a customer’s browser is going to take time, particularly for mid-size to larger businesses with thousands of scripts operating on the client side. Client-side attack surface monitoring and management solutions employ synthetic users and apply automation and artificial intelligence.
Recognize that you may need to upgrade your existing client-side solutions to be in compliance
Many tools and technologies no longer protect against the risks associated with the software supply chain, cloud platforms, and an evolving threat landscape, particularly on the client side. For example, web application firewalls (WAFs) can protect against some skimming attacks, but they won’t protect against the browser-level user interface itself and can’t detect and protect businesses from sophisticated skimming malware, drive-by skimming, supply chain attacks, or sideloading and chainloading attacks. The same is true with Content Security Policies (CSPs). Sometimes organizations assume that they can easily deploy a CSP on a web application or website just by creating it and then configuring the web server. But not every CSP is going to work for every web application. And if third-party code, plugins, or enhancements are added to the web page, policies may fail. If the organization is conducting an audit of this CSP to meet PCI DSS compliance, there’s also the risk that analysts will be unable to determine why policies failed.
Use an advanced, automated Content Security Policy tool
An automated CSP can help businesses control their client-side attack surface by deploying and managing Content Security Policies on their web applications. Advanced automated CSP tools identify all your first- and third-party scripts, your digital assets, and the data they can access. The tool then generates appropriate Content Security Policies based on scanned data and anticipated effectiveness. Businesses can fine tune their CSPs at the domain level for easy management, version control, and reporting.
Create a PCI 4.0 team
Create a team of compliance, software development, and cybersecurity professionals who will be responsible for PCI 4.0 planning and implementation.
Identify and monitor assets
Identify all of your assets, including software, web application code, and third-party scripts. Note any issues and their corresponding remediations.
Perform a risk assessment for PCI DSS scope
Determine what impact PCI 4.0 will have on your organization based on your existing system components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data, as well as impacts changes to these systems, people, or processes will have.
Achieving PCI DSS compliance—next steps
Client-side attack surface management tools can significantly help companies with PCI DSS requirements and assessments on the client side. For example, Inspector automates the process of asset identification and reporting to significantly reduce the time it takes for code reviews. PageGuard blocks all unauthorized and unwanted behavior in real time across an organization’s web assets, effectively preventing cardholder data exfiltration.
Experts highly encourage businesses to kick-star their PCI DSS 4.0 compliance efforts as soon as possible. Schedule a demo to see how client-side attack surface monitoring and management can support payment card industry compliance standards.
