New Card Payment Security Standards Are Coming. What Do They Mean for Your Business?

Like its predecessor, PCI DSS v4.0 is centered on 12 requirements that ensure safe transactions at your point of payment (POP) or point of sale (POS) pages. These core requirements did not fundamentally change with the latest release. Instead, v4.0 adds flexibility to implementation, strengthens security standards and necessitates a continuous process to ensure compliance.

There are several enhancements and amendments that might seem simple in theory, but will require significant resources in practice. One such addition is Section 6.4.3. This part of the DCI PSS tightens requirements for payment scripts, setting new regulations for script inventory, script integrity and script authorization — a difficult and significant undertaking, if done manually.

Take a walk on the client side

Section 6.4.3 of PCI DSS v4.0 establishes the following requirements for all payment page scripts that are loaded and executed in the consumer’s browser.

• A method implemented to confirm that each script is authorized.
• A method implemented to assure the integrity of each script.
• An up-to-date inventory of all scripts, maintained with written justification as to why each is necessary.

In essence, these requirements entail inventorying all code running on your payment pages, explaining the necessity of each and verifying that authorized code has not changed since determined safe. Manually achieving compliance will likely consume a lot of time, money and internal resources. Here’s why:

• Lack of visibility at runtime: Because payment page scripts run on the client side, website owners lack visibility into their behavior at runtime, especially code that loads dynamically. Code modifications, including malicious code injections, can evade detection for weeks.
• Frequent code changes: Third-party scripts are frequently updated and changed, sometimes without your immediate knowledge. So, even if client-side scripts pass an initial security review, modifications can introduce new risks. Over 50% of website owners report that their third-party scripts change at least four times a year.
• Nth party vendors: Third-party code vendors may themselves obtain code from external libraries. This lengthens your software supply chain and increases your surface area of vulnerability. If an nth-party script down the line is vulnerable, it can put your entire supply chain at risk.
• Insufficient security reviews: When it comes to software development, speed is often the name of the game. Developers may forgo a robust security review process if it slows down deployment. But even if an initial review is conducted, it does not cover future script modifications.

Business impact of PCI DSS v4.0

Under PCI DSS, brands are liable for any exposure of users’ payment data — malicious or otherwise.

Businesses that are not PCI compliant are at greater risk of a digital skimming, Magecart or supply chain attack. This can cause significant financial losses due to the time and resources spent on remediation, lawsuits and bad press. Furthermore, customers, partnering banks and payment processors may end their business with you after a breach.

In addition, PCI DSS can fine companies up to $500,000 per incident, depending on the size of the company and the scope of the violation. Receiving a noncompliance fine can damage customer trust and smear your brand reputation.

By maintaining compliance with PCI DSS 4.0, online businesses can avoid fines and reputation damage. This also instills trust in consumers that their payment data is safe on your site.

Legacy solutions are not enough

Traditional code-monitoring solutions can help you comply with PCI DSS v4.0, but most are not sufficient to actually detect and prevent all JavaScript attacks. There is an entire skimming as a service industry selling skimmer kits with malicious scripts that are able to evade traditional detection tools. Some examples:

• Static code analysis or static application security testing (SAST) debugs source code before a program is run, but sophisticated hackers can develop malicious code that only loads in real environments and hides when code analysis is running.
• External scanners analyze script behavior in an external sandbox to offer immediate visibility without having to deploy anything to your site. However, they only capture a moment-in-time snapshot and cannot detect code that loads dynamically in the browser.
• Content security policy (CSP) lets you enforce a preset allow list of known domains from which inline scripts can be loaded and data transferred. Unfortunately, CSP is difficult to manage and bad actors can use trusted domains to bypass CSP.
• Payment iframes allow a payment form hosted by a third party to be embedded within a brand’s webpage. iFrames are considered a secure method for achieving PCI DSS compliance, but sophisticated hackers can bypass iframe protection and skim credit card data.
• Behavioral monitoring automates inventorying and baselines client-side script behavior to flag anomalous activity in every user session. Behavioral monitoring is the best way to detect malicious code, get visibility into your client-side supply chain and proactively identify potential privacy or PCI compliance issues.
• JavaScript blocking restricts form field access for client-side JavaScript. It prevents this code from accessing sensitive data, enforcing data security and compliance without disabling the entire script. JavaScript blocking allows website owners to control script access, but it can’t identify which scripts should have access to which form fields.

This article was first published at PerimeterX.com. It is republished here with permission.