By Source Defense

There’s an old saying that leaders can delegate authority but not responsibility. That remains relevant and true in the digital supply chain. Companies can give their supply chain partners authority to operate on their websites, but responsibility for what that 3rd, 4th, and 5th-party code is doing ultimately rests with your internal security team.

Security practitioners struggle to keep up with the volume and pace of cybersecurity incidents, are overwhelmed by alerts and false positives, are distracted by new and evolving compliance requirements and are under pressure to show value to business peers. But the corporate website—often the centerpiece of the enterprise revenue model—presents a structural security risk that could mean the difference between business success and failure.

In the browser, client-side processes are almost always written in JavaScript. According to our team’s latest intelligence, there are more than 1.7 billion public-facing websites worldwide, and JavaScript is used on 95% of them. Frontend JavaScript code has grown in size by more than 347% for desktop and more than 593% for mobile during the last 8 years and keeps growing. 

And therein lies the structural security issue that poses one of the biggest threats to your most critical business channels—protecting your customer data at the point of entry. Javascript is used by all of your 3rd party digital suppliers, including payment card processors, advertising networks, social sharing services, analytics, and more, and it sits outside your security perimeter and is vulnerable to a wide range of attacks. 

How Much Do You Know About Your 3rd Party Attack Surface?

As a security team, if you still aren’t convinced that taking action to secure client-side transactions like payment card entry is an immediate necessity, the latest release of the Payment Card Industry Data Security Standard (PCI DSS version 4.0) has decided for you.

PCI DSS v4.0 section 6.4.3 states explicitly in its guidance that payment page scripts that are loaded and executed in the consumer’s browser must be managed as follows:

  1. A method is implemented to confirm that each script is authorized.
  2. An inventory of all scripts is maintained with written justification as to why each is necessary.
  3. A method is implemented to assure the integrity of each script.

Ensure Authorization & Justification

The first 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 used in constructing a modern web page, it becomes a highly 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.

Ensure Integrity

PCI DSS also states that the “integrity” of each script should be verified. 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 guidance 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 goal through static assessment or technology like Subresource Integrity suggests that a security team can 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 ensuring integrity is that client-side code often changes, by design, when a webpage loads. When vendor code is requested by a web browser, it may change a variable, add a token to identify the visitor, or perform some other dynamic function that 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?

PCI DSS 11.6.1

PCI section 11.6.1 states that change- and tamper-detection systems should:

  • Be deployed on payment pages to alert personnel to unauthorized modification
  • Evaluate the received HTTP header on the payment page
  • Meet these requirements every seven days or periodically

This means you must be alerted when a change has been made to a script operating on your website. Having the technology and resources to get these timely alerts is vital. While PCI is giving you leeway as to how much time you’re allotted to detect and respond to alerts, the question you need to ask yourself is, how much time can you afford to wait before you respond?

Source Defense Gives You Back Control

Source Defense forces 3rd party scripts to load within a virtual page isolated from the client-side. This isolation allows 3rd parties to behave in a controlled environment, enabling Source Defense to permit or deny behavior based on best-in-class security protocols, data privacy policies and standardized rules we have in place.

As the only purpose-built, patented technology for real-time protection and detection, Source Defense enables the client-side security controls called for under PCI DSS 4.0. And we do so with a solution that:   

  • Offers both code free deployment or deployment with a few simple lines of code 
  • Places no additional strain on your Security Operations team – with fewer than 5 hours of management per month 
  • Preserves the end-user experience
  • Eliminates unnecessary latency
  • Protects the customer journey
  • Delivers both security and data privacy compliance protections 

Source Defense helps enterprises balance superb customer experience with critical security without compromising website performance or stability. We create virtual pages that isolate the 3rd party scripts from the website. The virtual pages are an exact replica of the original pages, excluding what the 3rd parties are not supposed to see. We monitor all 3rd party script activities on the virtual pages. If the activity is within the premise of what they are allowed to do, we will transfer it from the virtual page to the original page. If not, we will keep their activity on the virtual pages isolated from the user and send a report to the eCommerce website owner, alerting them of the 3rd party scripts that violated their security policy.

With client-side attacks on the rise, ensuring that your customer’s payment and personal information are protected should be a priority if you want to avoid the implications of a data breach. 

Source Defense prevention solutions can protect your website from the growing threat of Magecart, Formjacking, and other digital skimming cyberattacks:

  • Isolating scripts from the page
  • Evading harmful activities
  • Applying best practices 
  • Securely enhancing websites
  • Keep benefiting from 3rd parties

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.

Scroll