Your Checkout Page Is Your Problem Too: What Quarterly ASV Scans Ask of Online Merchants

For years, many smaller online merchants treated card security as somebody else’s job. They sent shoppers to a payment provider’s hosted page, or embedded the provider’s payment form in their checkout, and assumed the card data, and the risk attached to it, never touched their own systems. Under the current version of PCI DSS, that assumption no longer holds for compliance, and for security it always carried risk.

WHAT CHANGED FOR SAQ A MERCHANTS

Merchants that fully outsource payment processing usually validate with Self-Assessment Questionnaire A, the shortest of the PCI DSS questionnaires. Under PCI DSS v4.0.1, SAQ A includes two external scanning requirements: quarterly scans by a PCI Approved Scanning Vendor (ASV) under requirement 11.3.2, and a scan after any significant change under requirement 11.3.2.1. The PCI Security Standards Council said the scans were added “to help address common breaches that are targeting SAQ A merchant environments at alarming rates.”[1] Under the previous version, PCI DSS v3.2.1, a merchant that redirected shoppers to a payment provider or embedded its payment form did not need these scans at all.

The reason lies in how card data is stolen from these sites. The scan covers the merchant’s own website, the page that sends customers to the payment provider or embeds its payment form.[1] If attackers compromise that page, they can change where the redirect points, or inject a script that swaps the payment form for a fake one and captures card details as the customer types them. The card data leaves before the payment provider ever sees it. The provider’s systems can be in perfect order and the customer’s card details are still stolen.

WHAT AN ASV SCAN LOOKS AT

An ASV scan examines internet-facing systems the way an outside attacker would see them. It looks for exposed services, known vulnerabilities in web servers and frameworks, outdated software, weak encryption settings and misconfigurations. Under the PCI Security Standards Council’s ASV Program Guide, a component generally fails the scan if it carries a vulnerability with a CVSS base score of 4.0 or higher.[2]

A passing scan, once attested, gives the merchant an Attestation of Scan Compliance for the external scanning requirements. It does not cover the rest of the standard, and full compliance depends on everything else PCI DSS asks for.

PLAN FOR WHAT THE SCAN FINDS

Teams that are new to quarterly scanning tend to plan for running the scan and forget to plan for what it finds. In practice, the work happens in the gap between the first result and the deadline.

Start with scope. Make a list of every domain, IP address and public-facing system involved in the payment journey, including the pages that redirect to the provider or load its payment form. A scan of the wrong assets can pass and still leave the checkout exposed.

Then leave time to fix what the scan finds. Each quarter needs room for the fixes and for a rescan that confirms the issues are remediated, all before the deadline arrives. A team that schedules its scan in the last week of the quarter has no room for the patch, the configuration change or the conversation with a hosting provider that a failed result usually needs.

Keep evidence as you go. If you patch a vulnerability, fix a certificate issue or rely on compensating controls, disputing a finding will need evidence of it. That might be a screenshot or a command that needs to be run, and gathering proof of remediation early saves time if a finding is disputed later.

Finally, know how to handle results you disagree with. Scanners produce false positives, and some findings need to be validated in your own environment. ASVs have a dispute process for findings that do not apply, or that need additional validation because other compensating controls are in place. The dispute is supported by evidence such as configuration details or confirmation from a vendor. Findings that explain what to fix shorten this step considerably, because the team can tell quickly whether a finding needs a fix or a dispute.

WHERE THE BUYING PROCESS SLOWS MERCHANTS DOWN

Many of the merchants now facing this requirement have small teams and limited security budgets. They often know exactly what they need: a quarterly scan of a handful of systems from an approved vendor. What slows them down is often the buying process itself, which eats into the time the first quarter leaves for fixes.

Merchants do not all want to buy the same way. Some want a scoping conversation with an expert, and larger environments usually need one. Others want to choose what to scan, pay and start the same day. Whichever route a merchant takes, the first scan needs to happen early enough in the quarter to fix what it finds.

THE QUARTERLY SCAN IS JUST THE START

A quarterly scan is a minimum standard, and attackers do not work to the same schedule. A site that passes in January can be vulnerable in February if a new flaw is disclosed in the framework it runs on, or if someone changes the checkout page without telling the security team.

So treat the ASV scan as just the start of checkout security. Between scans, track changes to the pages that handle the payment journey, keep the software behind them patched, and know who is responsible for each. Outsourcing payment processing removed a large part of the burden from these merchants. It did not remove responsibility for the website that hands their customers to the payment provider, and attackers target that website.

John Stock is a Senior Product Manager at Outpost24, a PCI Approved Scanning Vendor for more than 20 years.

SOURCES

1. PCI Security Standards Council, “Resource Guide: Vulnerability Scans and Approved Scanning Vendors”, July 10, 2024. https://blog.pcisecuritystandards.org/resource-guide-vulnerability-scans-and-approved-scanning-vendors

2. PCI Security Standards Council, ASV Program Guide.

______

About John Stock

John has nearly 30 years of experience in IT security, beginning his career at one of Europe’s largest energy providers before moving into penetration testing and later product management, where he combines his technical expertise with a passion for building innovative security solutions.