SAQ-A 6.2 – This one inclusion has changed the way we need to look at web servers.
PCI DSS version 3.2.1 was introduced earlier this year. Until the end of the year you can still assess against the previous version, but time is soon running out.
One of the changes introduced isn’t in the standard itself but in the Self Assessment Questionnaire (SAQ), specifically SAQ-A, which is used by many people who only use PCI Compliant third parties for their ecommerce sites and use one of the following three methods to reduce their scope.
- Method 1 – Outsource everything, website, payments etc.
- Method 2 – URL redirect. When the customer has to pay, they are redirected to a third party payment platform and the payment is processed there.
- Method 3 – iframe. The website provides a link to an iframe which embeds the payment page from the provider in the page of the merchant website. When submitted the card information goes directly from the client’s browser to the payment provider.
Using any of these three methods meant that the company had very few requirements to meet, and originally none on the web server that was doing the redirecting or providing the iframe link. Using any of these three methods meant that the web server hosting the links was considered out of scope.
The Payment Brands (Visa, Mastercard, AMEX Discovery and JBC brands still expected you to take reasonable measures to secure it but, from a PCI DSS perspective, the server was considered out of scope and therefore did not need to be managed in a PCI DSS compliant manner. From a security perspective this was, to be honest, a weird position because we all know that if you control the server that provides the links, you control the payment flow and bad things can happen. However, remember, PCI DSS is not really there for you and me, it exists to reduce the risk to the card brands. Some worked under the assumption that if you were no longer receiving funds, you’d probably figure out, fairly quickly, that there was an issue, therefore, there was no real need to protect the web server.
That was a long introduction to say this: It is no longer the case. The Web server is now in scope for PCI DSS for at least one requirement.
In SAQ-A, an additional requirement has appeared, Requirement 6.2, that applies to the web server you are using to redirect to the payment page.
|PCI DSS Question||Expected Testing|
|6.2||(a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches?||
|(b) Are critical security patches installed within one month of release?||
If you are using method 1, everything is hosted elsewhere and you have no responsibilities for managing it, then you can answer ‘Not Applicable’.
If you are using method 2 or 3, then you will have to get a patching process in place and patch the server in a reasonable amount of time. And if you do not answer ‘yes’ you will not be compliant.
This change of view also has some implications for the other requirements in SAQ-A. The other requirements that are applicable for this SAQ now also should be evaluated on the web server used to provide the redirects.
If you are unsure whether an SAQ-A could apply to you, have a look at the guidance published in the PCI Security Standards Council’s document Best practice for Securing E-Commerce.
If you need help or have any questions, ask your QSA, or ask ours using the contact form.