In March 2022, the Payment Card Industry Security Standards Council released a revised version of its Data Security Standard, commonly known as PCI DSS v4.0. This update includes a number of enhancements to ensure that consumers are protected when they make purchases online. As has been the case with previous updates, changes in v4.0 reflect the effort of the PCI Council to stay up to pace with the evolving threat landscape and ensure that new, favored attack methods of our adversaries are addressed.
A critically important section of the Standard specifically identifies client-side web security as essential for any business accepting payments online. This comes as no surprise to us, as the pace of client-side attacks has been on the rise for some years now and the risk of these attacks has proven to be material to some of the world’s largest organizations (and their customers) like British Airways, Macy’s and Segway to name but a few. These changes may come as a bit of a surprise to you and that’s why we want to make sure that you understand what this guidance means. Every security practitioner responsible for a public-facing website that accepts payments should inform themselves thoroughly of the implications of this deceptively straightforward change.
Client-side Security and Online Payments
Client-side security, put simply, is making sure that the parts of a web application that live inside of a visitor’s web browser are safe and are behaving as intended. This includes both the code developed by an internal application team, for instance, as well as the code provided by outside vendors.
Client-side security presents a unique challenge for three reasons:
- It deals with software (the front-end of the web application) that is not within the “perimeter” of an organization’s control…expanding the attack surface you need to secure.
- It involves code written by outside parties (e.g., vendors) which is downloaded and executed from servers not under the organization’s control…making this a critical area of third-party risk to mitigate as part of your focus.
- Total trust is extended to any code running within the client (e.g., a web browser) without any security controls or reporting features…negating your attempts to implement a zero-trust security strategy should you leave this unaddressed.
These facets of client-side security led to an environment ripe for exploitation. A client-side attack can originate from insecurely developed or hosted internally developed code. It can also come from vendor code (sometimes called 3rd or 4th party code) which the web application downloads and executes dynamically inside the visitor’s web browser.
Attacks can take the form of data theft, content defacement, user session hijacking, malware infection, and more. Further, attacks can persist for months or even years because of how difficult they are to detect. For a primer on client-side attacks, read our recently published whitepaper.
PCI Brings Down the Hammer
Client-side security has been a known security challenge for at least ten years, however, PCI DSS v4.0 brings real weight to bear on organizations that process payments online. Hardening the front-end of the web application is not just a nice-to-have line of defense but a key component of compliance and security strategy. We’d go so far as to say that without addressing the client-side, your web security strategy is incomplete.
PCI DSS v4.0 section 6.4.3 specifically states that:
[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.
At first blush, these requirements seem straightforward, but they have some real teeth in terms of security policy and practice.
The first requirement and third requirements essentially call for inventorying all code running on payment pages and ensuring they are necessary. This may seem straightforward but considering the breadth and depth of code involved in constructing a modern web page, it becomes an extremely daunting task.
In the case of vendor code, aside from the multiple code sets which vendors provide directly, they frequently include, on the fly, their own dependent applications. A customer support chat tool may load an analytics tool from a fourth party, and so forth. Untangling this web of relationships is difficult even when the list of vendors is relatively static which is rarely the case with contemporary web applications.
In the case of internally-developed code, there may be thousands if not millions of lines of code to identify and authorize, including many open source libraries which have been shown time and time again to be an immensely successful attack vector.
The second item listed in this section requires that the “integrity” of each script is verified. Put simply, this means that some mechanism exists to ensure that the code has not changed since some point in time when it was verified to be non-malicious.
This requirement is difficult to achieve due to the nature of client-side code. In the first case, it changes frequently. Vendors continuously update their products to release new features and fix bugs. Meeting this requirement through static assessment, or through a technology like subresource integrity, suggests that it is possible for a security team to review vendor code frequently and then freeze that code to a particular version. This is usually not possible if the code is hosted externally.
The other more fundamental difficulty with meeting this requirement is that client-side code often changes at the time a webpage loads by design. When vendor code is requested by a web browser it may change a variable, or add a token to identify the visitor, or perform some other dynamic function which is baked into the code as it is being sent to the web browser. How does one identify the integrity of code if it changes when it loads?
The enhanced security measures outlined by this section of PCI DSS v4.0 are valid and important steps towards the maturity of client-side security where payments are processed in a web browser. Despite their relative simplicity, the effort required to achieve compliance with these rules is actually quite enormous. Between inventorying scripts, identifying necessary behavior, baselining code behavior, managing relationships between vendors, digital marketing teams, application development, and security personnel, and a myriad of other tasks, PCI DSS v4.0 6.4.3 is a monster of a requirement.
Time, Money, and Effort
Meeting the challenge of complying with these new regulations is certainly possible. There are technologies available that help to meet these requirements, and some are even included in DSS v4.0 itself. There are, however, other considerations to weigh when deciding how to approach this set of rules.
- How much time can my security team invest in meeting these requirements? Do we have the necessary skills in-house, or will additional hires be necessary? And further, how much time will be asked of application development, digital marketing, or other teams involved in meeting these standards?
- How much is this going to cost? The code integrated into payment pages is some of the most important in any web application — it literally generates revenue. What sorts of friction will emerge as security needs directly impact revenue generation, and how can that friction be mitigated? What about lost revenues in the case of breach-related downtime required for remediation?
- Does our organization have the appetite for another cybersecurity program right now? Although PCI only added a few sentences about client-side security, properly addressing them and maintaining compliance requires policies, procedures, personnel, management, and maintenance. Is that something which matches the goals and the priorities of the organization, or is it another uphill battle amongst other initiatives vying for attention and resources.
These are new problems which security leaders will need to grapple with in the coming years not just because of these amendments to PCI DSS but also because of the constant and rapid evolution of client-side security as a whole. As the proverb says, “mighty oaks from little acorns grow.”
Problems, Technologies, and Solutions
BUT – what if you could address the expanding attack surface that is the client-side, mitigate this area of third party risk, get ahead of compliance with PCI, support your zero-trust ambitions…and do it all without the need to build out yet another security program?
The good news is that Source Defense saw all of this coming and we’ve developed a solution that can help you accomplish the desired outcomes either explicitly or by demonstrating compensating controls.
At Source Defense, we have been developing technology for nearly ten years to address exactly the concerns raised by these additions to DSS v4.0. Through our expertise in client-side security, we can deliver solutions to secure merchants and help them achieve compliance at a low cost, with little-to-no operational burden, and without massive new internal efforts.
Our technology provides real-time insight into every piece of code running on every page of your site during every pageview thereby rendering point-in-time analysis obsolete. Beyond just insight, however, Source Defense can provide real-time management of code behavior as it executes to ensure not only the integrity of your code but the ability to prevent client-side attacks before they cause damage to your company or your visitors.
Another expression to ponder is this:
“And many strokes, though with a little axe, Hew down and fell the hardest-timber’d oak.”
Here at Source Defense, we like to pay attention to acorns before they grow into oaks. And we make pretty good axes, too.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.
