E-skimming, formjacking, Magecart attacks…with the COVID-19 pandemic, in-person payments decreased, and we saw a rapid push to more activity online. Sadly, with this significant shift to online payments, there has also been a rise in e-commerce attacks. In fact, according to a new study from Juniper Research, losses to online payment fraud will amount to $206 billion between 2021 and 2025.
Attackers go where the money is and they have found ways to steal payment card data from ecommerce websites by injecting JavaScript code. The malicious code, often referred to as an “e-commerce skimmer,” will read credit or debit card information from the page, and send it back to the criminals who can then use that payment account data to make fraudulent transactions. Similar to physical device skimmers, the attacks are typically so successful because they don’t stop the authorized payment from going through, but rather just steal a copy of the card data as it is transmitted.
If your organization’s merchants are outsourcing to an ecommerce vendor, it remains critical to verify they are only utilizing compliant third-party service providers and that you are monitoring their compliance status on an ongoing basis. Remember, you can never completely outsource your PCI compliance responsibility and you still play a role in ensuring that the appropriate security controls are in place to protect any e-commerce sites that contain a payment component.
PCI DSS version 4.0 includes stricter controls to help protect organizations against online payment fraud. Specifically, in the SAQ A, which applies to environments where all processing of account data is entirely outsourced to PCI DSS compliant third-party services, we have seen an increase from 24 to 31 requirements that must be met.
Since unpatched vulnerabilities are one of the most consistent and primary attack vectors, new Requirement 6.3 states that security vulnerabilities must be identified and addressed. Any merchant website that implements an iframe provided by a third party to process payments or re-directs customers to a third-party website for payment collection, must be actively monitored for any vulnerabilities that could impact their e-commerce system. A documented procedure for ranking associated risks and deploying any necessary updates/patches is also required.
Requirement 6.4.3 requires payment page scripts to be managed as follows:
- A method is implemented to confirm that each script is authorized.
- A method is implemented to ensure the integrity of each script.
- An inventory of all scripts is maintained with written justification as to why each is necessary.
This applies to any page(s) on the merchant website that are used to redirect the customer’s browser to the third-party payment page. To comply with this requirement and reduce the possibility of malicious scripts making it onto your organization’s payment pages, document an inventory of all the known scripts used on any page involved in the overall process, including other third-party scripts in play. This inventory can then be tracked to ensure that all the scripts in-use are authorized. This can also be used to develop procedures for managing known third-party scripts, and help verify the payment page is only accepting data to process a transaction and is not full of additional JavaScript for tracking behaviors, support, etc. This ongoing confirmation of installed JavaScript can be done through manual or automated processes.
Requirement 8 did not have any significant updates but does have some additional password controls (requirements around length [now 12 characters], complexity, timeline for expiration, comparison against previously used passwords, etc.) that you should be aware of.
Requirement 11.6.1 mandates that change and tamper detection tools must be deployed on any web- based payment pages to alert personnel to unauthorized modifications (i.e., changes to script, additions, deletions, etc.) to the pages by comparing the current version of the HTTP header and the active content of the pages with prior or known versions. This requirement is applicable only to the SAQ when merchants are providing a payment page through an iframe. If your website simply re-directs customers to the third party payment site (via a Pay Now button or other), this requirement can be marked as Not Applicable (N/A).
Another change worth noting in PCI DSS v4.0 is Requirement 11.3.2. External vulnerability scans are now required for all e-commerce merchants, even those qualifying for the SAQ A. These scans must be performed quarterly by a PCI SSC Approved Scanning Vendor (ASV). Any identified vulnerabilities must be resolved and rescans must be performed as per the ASV Program Guide.
Under PCI DSS v3.2.1, if your website is just re-directing customers to a third-party payment page, requirements like external scanning are not required. However, with the prevalence of the Magecart and e-skimming attacks, it is equally important to ensure you are implementing security controls to protect the re-direct link from hijacking, so customers do not end up entering their cardholder information on a fraudulent site.
Although merchants do have until March 2024 to attest compliance using PCI DSS version 4.0, that does not mean you should wait until then to start addressing some of the updated requirements. We recommend that you begin evaluating your current online payment sites and processes, and documenting IP addresses and relevant information about any re-direct servers so they can be scanned accordingly.
For any questions or to have your dedicated QSA take a look at how your ecommerce merchants are configured, don’t hesitate to reach out to your CampusGuard Team. It can be helpful to just sketch a quick card flow diagram that outlines the overall payment process. CampusGuard is also an Approved Scanning Vendor (ASV) so can assist with any needs for external scanning.
Additional guidance from the CampusGuard Security Advisor team below:
[Ko]: Whoa! We haven’t seen a change to an SAQ like this since the SAQ A-EP’s debut with PCI DSS 3.0! The ever-changing threats targeting e-commerce environments has the PCI Council responding with major changes to the fully-outsourced e-commerce SAQ.
What this means to you is that the web servers used to redirect your consumers to third-party payment pages may no longer be the same “set-and-forget” operation that you may be accustomed to. If you have taken full advantage of using an iframe integration of the payment page, the majority of the changes to the SAQ A apply to you. If you are still using a full web redirection method, you will still likely have to manage at least a few of the new requirements, but, there may be situations where those new requirements could have less of an impact.
We all know that time waits for no one—and March 2024 (and 2025 for evolving requirements!) will be here sooner than we want it to. I’m not, by any means, telling you to start validating compliance against the 4.0 standards this year—I mean, if you are able to, more power to you, and way to go! But, if you’re like the rest of us, we probably want to finish out this year strong, continue validating against PCI DSS 3.2.1, then, start planning for what 4.0 validation looks like. It’s during this stage that you should be looking at options surrounding what full compliance will look like if you run it in-house, outsource it, or change the way you handle those web redirection methods. Talk to your departments and end-users early and often to make sure you can still service your customers with whatever changes you plan on making to get to be fully compliant with PCI DSS 4.0.
