In May 2016, Sysnet posted an early update of the changes to SAQ A v3.2 prior to the retirement of SAQ A v3.1. Version 3.2 has been mandatory for some time now, in this follow up article we hear from one of Sysnet’s QSAs, Michael Hopewell. He recounts his experiences in the field on how merchant businesses have responded to the v3.2 SAQ and suggest steps that our readers can use to assist their business customers.
By Michael Hopewell, Managing Information Security Consultant
Let us first summarise the applicability and intent of SAQ A. This self-assessment questionnaire is applicable to entities that outsource their e-Commerce payment channel payment processing to a PCI DSS compliant third party.
It is the PCI DSS compliant third party that is responsible for all handling storage, processing, and transmission of payment card data; the entity at most retains only paper reports or receipts with cardholder data.
This applicability includes entities that have wholly outsourced their entire ecommerce website infrastructure to a PCI DSS compliant service provider as well as those that use a redirect or iFrame approach for their e-Commerce payment processing.
In the latter case, the customer enters their cardholder data on a PCI DSS compliant hosted payment page that is set-up either as a redirect from the entity’s website or embedded within an iFrame on the entity’s website.
As the newly published PCI SSC e-Commerce best practices guidance explains, even though payment card data is not collected, stored, processed, or transmitted by the entity’s own web server, that web server could still be compromised which: “could mean the redirect is changed to a bogus payment site in order to steal cardholder data—e.g., man-in-the-middle attacks wherein the web server collects and sends data to malicious individuals”.
It is therefore important to protect the website code that is conducting the redirect or iFrame. There are specific PCI DSS requirements within SAQ A that are intended to help minimise this risk:
- Vendor defaults have been changed and unnecessary default accounts removed (reqt 2.1);
- All users are uniquely identified and authenticated (reqt 8.1.1, 8.1.3, 8.2, 8.5);
- Strong passwords are being used (reqt 8.2.3);
- Terminated user accounts are de-activated or removed (reqt 8.1.3);
- An incident response plan is in place (reqt 12.10.1 a).
To address confusion as to the applicability of these requirements in the SAQ A, the PCI SSC has just published a revision which now includes an explanatory note for entities that redirect the customer from their website: SAQ A v3.2 rev 1.1
Changes in scope and impact
The redirect/iFrame code is stored on a web server, so this is going to be in scope. The PCI DSS requirements in SAQ A also refer to access control and password management, therefore the system conducting identification and authentication will also be in scope.
In my experience of conducting v3.2 assessments and engaging with all levels of merchant businesses, I have found that many are often surprised that these systems are in fact considered in scope. Often the main challenge relates to those business customers that manage their own web servers and access systems.
The reason for this is that web servers and access systems were never deemed by merchants to be in scope for PCI DSS previously, which consequently means these systems may never have had the appropriate level of protection.
However, what I more commonly find is that the web server and access systems are hosted and managed by a third party. As a result, merchant businesses must now engage with their third party provider in order to complete their self-assessment. The business needs to demonstrate compliance by obtaining the appropriate evidence from the third party.
If the systems are not PCI DSS compliant, the third party will need to undertake remediation and uplift the current control measures to comply with these new SAQ A requirements.
I have also noticed during my time out in the field that often business customers do not seem to have an Incident Response Plan (or have insufficient detail and content in their current Incident Response Plan). Merchant businesses need to consider the threats and risks to their website that could result in cardholder data, and indeed personal data, being stolen.
In addition, they need to determine how website attacks or breaches would be logged, reviewed and acted upon by both their third party providers and themselves. At the very least the merchant business should have the relevant teams in place and know exactly who to contact in case a security breach occurs so that they can minimise any damage.
Steps for your business customers to take
Here are some recommendations:
- Identify the assets in scope for the SAQ A requirements (web server and access systems)
- Identify the teams managing those assets
- Develop and apply secure configuration standards for:
- The web server
- The access management system (such as Active Directory that controls access to Windows-based servers)
- Ensure there are documented policies and procedures governing user account management. This should detail how to add, remove and modify unique user accounts
- Ensure there are documented policies and procedures governing password management. For example, ensuring default passwords are not used, defining a minimum length of seven characters and using complex password
- Develop an Incident Response Plan to be clear what to do in the event of a breach. At a minimum, that plan should document how to engage with third parties, acquirers and payment brands. Where the web server and access systems are hosted and managed by a third party, the plan will also need to include the third party’s reporting of incidents and breaches to the business customer and the actions to be taken.
If you are a merchant that requires technical or PCI DSS help, please click here
Read the article and download our free Incident Response Plan: