PCI DSS 4.0 External Compliance Scan

[Mantra]

Security Metrics is a PCI Approved Scanning Vendor so their scan results should be acceptable.
https://listings.pcisecuritystandard...anning_vendors

[graphicz]

Indeed but the account is in my name and do not really want my name associated with a client company

[Mantra]

I don't normally read the forums, but I've just completely read this thread.

I've been spending a lot of time researching PCI DSS in the last month and in particular the newer requirements for v4.0 that will become mandatory at the end of March 2025. These are 6.4.3 and 11.6.1 in SAQ A, as noted in https://www.securitymetrics.com/blog...40-saq-changes . 6.4.3 relates to checking the integrity of all scripts on a payment page, and 11.6.1 is about checking the contents of the payment page (including scripts, headers, HTML) and making sure that all changes are valid.

The reasoning behind these changes is clear: the payment page itself is vulnerable to scripts being injected and being used to skim card details (Magecart-style attacks). In a Sellerdeck Desktop site that could happen at all sorts of levels, from changing of scripts in the site folder, or changed layouts e.g. Javascript Header Functions, to changed scripts coming from a third party like polyfill.io.

So the new requirements for next year should stop this sort of attack. If something is changed you should be prompted to fix it - or approve it - immediately. I'm looking at how they can be fulfilled in Sellerdeck Desktop, probably using an external service.

The implication of this is that it's not the use of ClearAccept which is causing PCI DSS compliance to be needed. SAQ A is very clear that any payment page, whatever method is used - either iframes or a hand off to another site - is in scope. I've been in discussion with PayPal because their guidance around PCI DSS is misleading and they will be changing that. They'll also be changing the integration methods so that 6.4.3 can be applied - i.e. integrity checking.

I'm involved with a wider advisory group within ClearCourse, and we're meeting with a PCI DSS Qualified Security Advisor next week. I've prepared questions for that session, and will also be describing the Sellerdeck Desktop architecture.

Some of these questions relate to the ClearAccept PCI Portal which I've been using on a test basis. There are some confusing questions which I want to clarify. There is also a template Information Security Policy which is out of date, and I'll be asking about provision of an appropriate policy for SAQ A which most merchants will be able to use.

And to come back to that mention of polyfill.io - we identified this as a risk in March because ownership of the site has moved to a Chinese entity. We did a special announcement (those on 18.2.3 will know about those!) and also posted a KB article about it at https://community.sellerdeck.com/for...rdeck-software. However, only 42% of the Sellerdeck Desktop ClearAccept sites have followed those instructions. Google have now caught up and have started emailng merchants today saying that Google ads will be suspended until it's removed. That might cause a few more to apply the change!

Apart from the solution to the polyfill.io that is self explanatory and bearing in mind that the end of March 2025 deadline for compliance with PCI DSS v4.0, 6.4.3 and 11.6..1 is fast approaching, please can you provide an update on the questions raised.

[Hugh Gibson]

Apart from the solution to the polyfill.io that is self explanatory and bearing in mind that the end of March 2025 deadline for compliance with PCI DSS v4.0, 6.4.3 and 11.6..1 is fast approaching, please can you provide an update on the questions raised.

Research is ongoing. I've discussed solutions for 6.4.3 and 11.6.1 with 5 different providers, with a range of costs and implementation details. We're also looking at the implications of the standards for merchants, particularly around the way that MOTO is handled. We plan for the next release to incorporate some changes to make it easier to comply with the requirements.

I'm in a regular call with Colin Clark, the head of PCI for ClearAccept's acquirer, Worldline. I'm the "PCI Champion" for the ClearCourse Retail & Hospitality division, and work closely with other PCI Champions throughout the group.

[graphicz]

Hugh Gibson

SAQ A is very clear that any payment page, whatever method is used - either iframes or a hand off to another site - is in scope

So far there is a division between merchants using WorldPay/Opayo/Paypal who are OK on shared hosting platforms as long as their SAQ is OK and merchants using ClearAccept where card details are entered into the merchant's own website and thus he needs full PCI compliant hosting.

Are you saying that merchants with websites on shared platforms where card details are entered on the separate PSP's website will at some point need full PCI compliant hosting?

That would affect thousands of businesses.

Thank you

[Mantra]

PCI Drudgery

Just checked the guidance on PCI Security Standards Council website to find that PCI DSS v4.0 is being retired on 31 December and replaced by PCI DSS v4.0.1 - Hey Ho!!

Compliance with Requirements 6.4.3 and 11.6.1 will still be considered best practice until 31 March 2025.

Requirement 6.4.3 Guidance has been updated - copied below:

Good Practice
Scripts may be authorized by manual or automated (e.g., workflow) processes.
Where the payment page will be loaded into an inline frame (iframe), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorized content being substituted for the payment page.
Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement, in accordance with the TPSP’s/payment processor’s PCI DSS assessment and Requirement 12.9.

Examples
The integrity of scripts can be enforced by several different mechanisms including, but not limited to:
• Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with.
• A CSP, which limits the locations the consumer browser can load a script from and transmit account data to.
• Proprietary script or tag-management systems, which can prevent malicious script execution.

Requirement 11.6.1 Guidance has been updated - copied below:

Good Practice
Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement, in accordance with the TPSP’s/payment processor’s PCI DSS assessment and Requirement 12.9.

Examples
Mechanisms that detect and report on changes to the headers and content of the payment page could include, but are not limited to, a combination of the following techniques:
• Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives.
• Changes to the CSP itself can indicate tampering.
• External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.
• Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected.
• Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel.
The above list of mechanisms is not exhaustive, and the use of any one mechanism is not necessarily a full detection and reporting mechanism.
Often, these mechanisms are subscription or cloudbased, but can also be based on custom and bespoke solutions.

[graphicz]

Regarding 6.4.3, when adding security headers to htaccess is there a list of PSP source urls we can use to specify the correct source for frame-ancestors so that legitmate PSPs are not blocked?

One or more sources can be set for the frame-ancestors policy:

(https://developer.mozilla.org/en-US/...rame-ancestors)

Content-Security-Policy: frame-ancestors <source>;
Content-Security-Policy: frame-ancestors <space separated list of sources>;

To reply to my own question:

To get the URLs for all legacy payment methods, you would need to find an installation of v18.2.2 and go to: -

C:\Program Files (x86)\Sellerdeck\Sellerdeck v18\OCCUpgrade

and open the file: -

OCCUpgrade.ini

Inside that file, you will find all the URLs that the software calls for each payment method.

[Hugh Gibson]

Hugh Gibson
So far there is a division between merchants using WorldPay/Opayo/Paypal who are OK on shared hosting platforms as long as their SAQ is OK and merchants using ClearAccept where card details are entered into the merchant's own website and thus he needs full PCI compliant hosting.

Are you saying that merchants with websites on shared platforms where card details are entered on the separate PSP's website will at some point need full PCI compliant hosting?

That would affect thousands of businesses.

Yes, I'm saying that. And it will affect thousands of businesses.

PCI DSS SAQ A is required regardless of whether the customer clicks through to a separate credit card entry page, or use iframes embedded in the final page of checkout. If you look at SAQ A, in the eligibility criteria, there is:

For SAQ A and e-commerce channels, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s) that provides the address (the URL) of the TPSP’s payment page/form to merchant customers. This is because the merchant website impacts how the account data is transmitted, even though the website itself does not receive account data.

In this context, payment page means something like Opayo, where there is a separate page, and form means an iframe as used by ClearAccept. If you have a form which isn't an iframe then you have to use SAQ A-EP.

6.4.3 and 11.6.1 are all about adding extra checks to ensure that the payment page is protected. That's because of skimmer, or Magecart type attacks where an extra bit of JS is inserted into the page and captures CC details, exfiltrating them to a hacker's server. 6.4.3 has this note, making it clear that it applies to both payment page and iframes:

Note: For SAQ A, Requirement 6.4.3 applies to the page(s) on the merchant’s website(s) that provides the address (the URL) of the TPSP’s payment page/form to the merchant’s customers.

11.6.1 has the following notes, making it clear that it applies only when using iframes:

Note: For SAQ A, Requirement 11.6.1 applies to merchants that include a TPSP’s inline frame (iframe) payment form on the merchant’s website.

If a merchant uses URL redirects, where the merchant hosts the page(s) on their website(s) that provides the address (the URL) of the merchant’s payment page/form to the merchant’s customers, the merchant marks this requirement as Not Applicable and completes Appendix D: Explanation of Requirements Noted as Not Applicable.

If your hosting is not PCI compliant, can you guarantee that someone with access to the servers (either physically or through a hacked account) won't install a skimmer script? It's unlikely, but having compliant hosting increases the security level.

I've been immersed in PCI DSS since my original post above. I'm the PCI DSS chamption for ClearCourse Retail and Hospitality, and am in 3 weekly meetings discussing PCI DSS. One of those is with Colin Clark, head of PCI DSS at Worldline (ClearAccept's acquirer) who is very experienced in PCI DSS and has been invaluable in clearing up misconceptions. Colin rewrote the template Information Security Policy after I pointed out that the old one was out of date. That should be live in November.

I've met with 5 different providers of services which will help merchants meet 6.4.3 and 11.6.1.Colin was recently at the PCI DSS conference in Barcelona, and said that the council is putting together guidance on how those clauses can be met without using external tools.

We don't have all the answers yet, but we're doing a lot of work on them.