SBN

Preventing Malicious Script Execution: Do I Need a Proprietary Script Management System? “Yes” If You Want to Meet PCI 6.4.3

PCI 6.4.3 gives a nod to proprietary script management systems which have been created to specifically handle malicious script execution. The Payment Card Industry’s (PCI) guidance under 6.4.3 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

PCI’s guidance on 6.4.3 lists three potential solutions for organizations to meet these needs  — SRI, CSP, and/or a proprietary script management system. Let’s look at each of these to measure their effectiveness in meeting this new guidance.

SRI Doesn’t Satisfy All Three Requirements for PCI 6.4.3

SRI, or Subresource Integrity, is a type of file integrity monitoring (FIM) where the browser will load a given asset only if its hash matches the one that was defined ahead of time. Natively, SRI handles the first bullet point of PCI 6.4.3 but in a round-about way. The script hashes need to be added to your SRI list to authorize a script to run on a page. Plus, SRI also handles the integrity of each script which checks off the second bullet point requirement for PCI 6.4.3. 

However, SRI does not comply with the third bullet point, “An inventory of all scripts is maintained with written justification as to why each is necessary.” This is because SRI is simply a browser-native function. Thus, justification for each script would need to be kept separate and available to larger teams as necessary within your organization.

Additionally, SRI is notorious for being difficult to manage, maintain, and set up. Any time a script changes or updates (and these change by the thousands of times per year), a new hash needs to be created and loaded into your SRI hash list. This can be time-consuming and can cause website malfunctions when not kept up.

CSP is Based on Script Domain, Not Code

CSP, Content Security Policy, is similar to SRI in that a list needs to be created of the scripts running on a given page. Essentially, CSP defines a set of directions that will whitelist script domains. This list is based on script domain and allows for vendor code alterations and updates to happen without the need to re-authorize the script. Only some behavior restrictions can be set within a site’s CSP policy.

Yet, CSP is not a viable or sustainable solution to adhere to the guidance under PCI 6.4.3. The problem is that script authorization is based on domain and not code. This means that while you can explicitly give access to a script, you cannot assure the integrity of the script, and once access is granted, script behavior can be challenging to reign in. 

Similar to SRI, CSP is browser-native and no written justification system exists to allow for the written piece of 6.4.3’s guidance. The elephant in the room with CSP is that the original intent was to prevent XSS-based attacks while eSkimming and other client-side attacks are purely an afterthought. 

Proprietary Script Management Systems are the Ultimate Solution to Meet PCI 6.4.3

Source Defense is a proprietary script management system that meets all three elements of PCI 6.4.3. Let’s dive into each bullet point and uncover how the Source Defense platform is the ultimate solution to preventing malicious script execution.

“A method is implemented to confirm that each script is authorized”

For nearly ten years, Source Defense’s technology has been developed to serve as an authoritative source on client-side attacks such as magecart, formjacking, skimming, and other JavaScript-based attacks. The Source Defense platform audits and authorizes each script on a website and grants only the permissions necessary for the script to perform optimally without posing any risk.

“A method is implemented to assure the integrity of each script”

Source Defense protects the end-user experience by eliminating unnecessary latency and protecting the customer journey. This is done by ensuring the integrity of each 3rd, 4th and nth party script by forcing 3rd party scripts to load within a virtual page that is isolated from the visitor’s page. By forcing 3rd party scripts to behave in a controlled environment, Source Defense is able to give set permissions to allow or deny the script to conduct certain behavior.

“An inventory of all scripts is maintained” 

The Source Defense Client-Side Security Platform not only audits the 3rd and 4th-party script on a site, it also offers advanced security management in an all-in-one, scalable system for full threat visibility and control across all your client-side security products. Now, you have full visibility into your site’s inventory of 3rd-party scripts that are on each page of your site. This inventory details how many 4th-party scripts they’re bringing in, and what permissions each of these scripts has.

Final Thoughts

PCI 6.4.3 details three possible solutions. However, two of these “solutions” are insufficient at meeting all three points of guidance. To ensure your organization remains compliant and to protect your organization and clients from client-side attacks, you need to implement a proprietary script management system. 

Source defense is the script management system that will help you prevent malicious script execution. Request a demo of the platform to see it in action.

The post Preventing Malicious Script Execution: Do I Need a Proprietary Script Management System? “Yes” If You Want to Meet PCI 6.4.3 appeared first on Source Defense.

*** This is a Security Bloggers Network syndicated blog from Blog – Source Defense authored by [email protected]. Read the original post at: https://sourcedefense.com/resources/preventing-malicious-script-execution-proprietary-script-management-meet-pci-6-4-3/