Announcement

Collapse
No announcement yet.

PCI DSS 4.0 External Compliance Scan

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


      Indeed but the account is in my name and do not really want my name associated with a client company
      Jonathan Chappell
      Website Designer
      SellerDeck Website Designer
      Actinic to SellerDeck upgrades
      Graphicz Limited - www.graphicz.co.uk

      Comment


        Originally posted by Hugh Gibson View Post
        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.
        Martin
        Mantra Audio

        Comment

        Working...
        X