What Does PCI DSS 4.0 Mean for Client-Side Security? | Feroot

What Does PCI DSS 4.0 Mean for Client-Side Security?

31 May 2022

PCI DSS 4.0 couldn’t have come at a more opportune time, particularly as the global pandemic forces more individuals into online purchasing—from shopping and entertainment to healthcare and hospitality. With PCI 4.0 compliance mandated by 2025, it is critical to understand now what it will mean for client-side security, so businesses can begin the implementation process.

What does PCI DSS 4.0 mean for client-side security? Updates. New Requirements. What Businesses Need to Do to Be in Compliance.
PCI DSS 4.0 and Client-Side Security. Understand the updates, new requirements, and what businesses need to do to be in compliance.

PCI DSS 4.0 & Client-Side Security

There are too many battles going on in the world these days—not the least of which are those happening in the realm of sensitive consumer information, such as payment card industry data. For years now, threat actors have been scaling and innovating their arsenal to maximize the impact of data breaches. And, to a great extent, they’ve succeeded. According to the Identity Theft Resource Center 2021 Annual Data Breach Report, the overall number of data compromises is up more than 68 percent. And for the first quarter of 2022, publicly reported data compromises reflected a 14 percent increase compared to Q1 2021. So, it comes as no surprise that the announcement of the new PCI DSS 4.0 security standards, designed to enhance and improve payment card industry data security, was met with fanfare from industry leaders in security, financial services, retail, e-commerce, and any other sector that accepts, stores, or transmits credit card data. At the core of a number of the key PCI 4.0 data security standard changes are those that relate to client-side security. PCI experts at the Herjavec Group succinctly address why the new PCI DSS 4.0 requirements focused heavily on client-side security: “Generally speaking, the client-side web browser attack surface has been completely overlooked as a threat landscape except by malware authors, the hacking community, social media, and mass marketers.

What PCI 4.0 client-side security changes are there?

Before we dive into the detailed changes, let’s take a look at one of the major issues that is going to affect organizations immediately—and that’s timing.

While PCI DSS 4.0 isn’t scheduled to go into effect until 2025, to achieve compliance, businesses need to start the planning and implementation process now. That includes identifying all web assets and their sources, reviewing code, and establishing key best practices defined in PCI 4.0 now so you can demonstrate compliance to qualified security assessors (QSAs). 

Why is planning and implementation so important? Well, the big issue has to do with new requirements that specify that entities now must identify, inventory, and manage scripts operating in web browsers that collect payment information. If you’re a mid-size to larger business with thousands of scripts operating on the client side, identifying, inventorying, and securing all of those scripts is going to take time, particularly if you have thousands of lines of code to review.

As for the actual changes in requirements, some are fairly impactful when it comes to securing the client side.

Requirement 6

Organizations that collect, store, or transmit cardholder data owe some thanks to the folks at Payment Card Industry Security Standards Council (PCI SSC), because they’ve finally recognized that the client side needs some serious attention. For years, client-side threats have been treated like a giant black hole—hard to identify and interpret. Fortunately, that has changed with PCI DSS 4.0. Many of the new and updated requirements that focus on client-side security feature in Requirement 6.

  • Identify and list all bespoke and custom software. Requirement 6.3.2 specifies that in order to manage vulnerabilities and patches, entities are now required to identify and list all of their bespoke and custom software, including 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.”
  • Protect system components from known vulnerabilities. If you’re running any client-side scripts pulled from third-party libraries, you need to make sure you apply fixes. Requirement 6.3.3 calls for all system components to be protected from known vulnerabilities through the installation of applicable security patches and updates.
  • Address new threats and vulnerabilities pronto! PCI 4.0 client-side compliance mandates in Requirement 6.4.1 note that for public-facing web applications, “new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected from known attacks.”
  • Correctly configure automated public-facing web applications. Requirement 6.4.2 clarifies that automated public-facing web applications should be configured correctly to detect and prevent web-based attacks. The requirement also mandates that configurations should be actively running, up to date, and configured to block attacks or generate alerts indicating a potential issue. Any alerts should be immediately investigated.
  • Authorize customer browser scripts. For requirement 6.4.3, organizations will need to authorize any scripts that are loaded and executed in a customer’s browser. In addition, businesses will need to maintain an inventory of scripts with written justification as to why each script is necessary. Organizations must also implement a method to assure the integrity of each script.

Requirement 11

Requirement 11 also has client-side implications. 

  • 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. 

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. 

PCI DSS 4.0 Client-Side Best Practices

Start PCI DSS 4.0 security efforts now

The newly mandated PCI 4.0 client-side requirements will take time to understand, implement, and establish. 

Automate solutions that support PCI 4.0

Let’s face it. It is going to take some time to document and maintain inventories of bespoke and custom software in order to securely manage all the payment page scripts that are loaded and executed in a customer’s browser. And if you’re a mid- to large-sized company with thousands of scripts operating on the client side, you don’t want to be doing manual code reviews. Client-side attack surface monitoring and management solutions employ synthetic users to automate the inspection and inventory process. 

Upgrade your existing client-side solutions

Traditional security controls, like Web Application Firewalls (WAFs) do not protect against threats at the browser-level and can’t detect and protect businesses from sophisticated skimming malware, supply chain attacks, or sideloading and chainloading attacks. The same is true with Content Security Policies (CSPs). Unless you have a list of all third-party domains and scripts that doesn’t frequently change, it will be near impossible to build and manage CSP in a reasonable way. So, unless you’re using an advanced, automated content security policy tool, you won’t be able to easily deploy CSP for a web application or website. Additionally, a standard CSP is not going to work for every web application. And if third-party code, plugins, or enhancements are added to the web page, policies may fail. Finally, 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.

Create a PCI 4.0 team

Implementation and management of the new PCI 4.0 requirements necessitate expertise across a variety of areas, including compliance, software development, risk, and cybersecurity. 

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.

Client-Side Security and S-SDLC

Add client-side attack surface testing and monitoring to the secure software development lifecycle (S-SDLC).

Begin Your PCI 4.0 Client-Side Security Journey Now!

Client-side attack surface monitoring tools can significantly reduce the burdens associated with implementing and managing PCI DSS 4.0 requirements on the client side. For example, inspection tools automate the process of script identification and collection and can focus on identifying vulnerable or malicious scripts. Monitoring and management tools can block all unauthorized and unwanted behavior in real time across an organization’s web assets, effectively preventing cardholder data exfiltration. And advanced, automated content security policies can identify all  first- and third-party scripts, digital assets, and the data they can access and then generate appropriate content security policies based on scanned data and anticipated effectiveness.

Free Assessment

Security for Everyone that Visits Your Website

Find out if your web application is hiding vulnerable, malicious, or dangerous code that could damage your customers and your business. No payment information required.