PCI 4.0 Requirement 6.4.3 and 11.6.1
TL;DR
PCI 4.0 “best practices” 6.4.3 and 11.6.1 become requirements starting after March of 2025. While the language of those requirements is pretty straightforward, meeting those requirements might be a bit of a discussion between you and your auditor. I aim to shed some light on that, as best I can, and hopefully help you have that discussion.
⚠️DISCLAIMER⚠️
This is just my opinion. Beyond some time in the saddle doing security work (red and blue) and having a few audits under my belt, this is all just “Jeff's Opinion” on the subject. Your mileage may vary.
The Gory Details
If you're still reading this, you're a glutton for punishment, or worse, you're into this sort of thing. Lets get the ugliest bit out of the way right up front, the actual requirements:
6.4.3
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.
11.6.1
A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser. • The mechanism is configured to evaluate the received HTTP header and payment page. The mechanism functions are performed as follows: – At least once every seven days OR – Periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
My Opinion
I'm going to rephrase those in plain language and give some suggestions.
The Requirements (As Written) And What To Do About Them
6.4.3: This focuses on scripts on the payment page(s). You need to have a document that: • Lists every script on your payment page(s) • Explains why it is there • Validation that scripts aren't EOL'ed, have any CVE's, and are served via TLS from a trusted source. • For open source project scripts, a trusted source may require you to do a targeted risk assessment to support why you trust it. • Someone with some authority has reviewed and approved the above
Here are some things you can do to support your due diligence: • Run known/named scripts through a tool like Retire.js to see if common scripts are EOL or have vulnerabilities. (This is good for things like React, jQuery, etc.) • Check unknown javascript to see if they are bundled using a tool like Bundle Scanner. This will tell you if the script is a “bundle” of more than one common library, and what those are. You'll need to evaluate each of those individually. • Run the hashes of all scripts on your page against tools like VirusTotal and Hybrid Analysis to see if there are any detections from common AV engines.
11.6.1 This requirement basically ensures that you are validating the above regularly, and someone will be notified if the status changes. For this, there are a couple approaches: • Buy something that does this for you. • Build something that does this for you.
I won't go into products that will do this for you, but I'm positive someone out there will happily take your money. Hopefully after reading this you are better prepared to evaluate paid solutions. If they aren't detecting bundled scripts, skip it. That is, in my opinion, the most likely avenue for a supply chain problem.
The simplest DIY solution is to make a script that checks expected page headers and evaluates included scripts against the trusted list you created (and vetted) above, and alerts you if something new pops up or changes. Run that once a week, or as often as you decided in your TRA.
NOTE: The 11.6.1 requirement as it is currently written states as received by the consumer browser and evaluate the received.... This is worth noting because it specifically does not require things like dynamic analysis, sandboxing, DOM monitoring, etc. Those are great ideas, and you should know everything you can about what is running on your payment pages, but 11.6.1 does not currently require it.
Final Thoughts
My goal in this isn't to get you out of doing anything you should be doing. You should be taking every possible precaution to protect your payment pages. But, new requirements can lead to “blue sky thinking” and “inferred requirements”. Hopefully the above helps you to do the right thing without too much extra nonsense.