April 2015: SAQ A-EP v3.1
Although the council removed this from the table in the “Understanding the SAQs for PCI DSS v3″ doc, it was not removed from the criteria for SAQ A-EP v3.1:
“Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;”
And:
“All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor; ” ??????
Ad below this line:
SAQ A V3.1 April 2015
“All elements of the payment page(s) delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s).”
From SAQ AOC v3.0:
“I have read the PCI DSS and I recognize that I must maintain PCI DSS compliance, as applicable to my environment, at all times.”
From SAQ A-EP v3.0:
“SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.”
…”This shortened version of the SAQ includes questions that apply to a specific type of small merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to your environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment. Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI DSS compliant.”
Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;
Your e-commerce website is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate the website from all other systems);
April 2015: New Council Guidance: “PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v3.1” from here
“All merchants and service providers are required to comply with the PCI DSS as applicable to their environments at all times.”
From above graphic: “a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction”
“Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s);”
Is the total to be paid considered an “element”?
And then the guidance flowchart:
Picture from the September 2014 North American Community Meeting
PCI DSS V3.1 – the Scoping section
From graphic above: “may impact the security of (for example, name resolution or web redirection servers) the CDE”. Web redirection servers are in scope.
PCI FAQ
“The Council understands that the various ways that merchants can make e-commerce transactions is continually evolving. Merchants and QSAs receive often conflicting advice from vendors which can be especially confusing when the difference between using an iFrame and embedding a payment form in a <DIV> appears to be minimal. However, the difference in security is substantial: fully-hosted payment pages and payment pages loaded into an iFrame are resistant to the transparent theft of cardholder data as it is entered by the consumer; techniques such as Direct Post and JavaScript forms are not. The Council is aware that a MITM attack against a redirect or iFrame is viable, but in the payment brands’ experience these are detected before significant volumes of cardholder data are lost. The Council is working with Payment Service Providers to encourage tamper-resistance and tamper-detection which will also reduce the viability of a MITM-type attack.”
August 2014: Visa Europe’s Guidance
Thanks to Todd Roseman (@lukydesigns) for pointing me to this website which analyzes Visa Europe’s validation requirements for hosted payment pages. Direct link to Visa Europe’s document here.
May 2014: Council Guidance: “Understanding the SAQs for PCI DSS v3.0”
Graphic below from council guidance: “Understanding the SAQs for PCI DSS v3.0” Section: How does SAQ A-EP compare to SAQ A?
The row “Control of Cardholder Data” says:
“Merchant’s e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor“
April 2015 Council Guidance: “Understanding the SAQs for PCI DSS v3”
Curiously this doc is updated from May 2014, but still doesn’t reference PCI DSS v3.1.
The excerpted chart did change though:
The “Control of Cardholder Data” row is removed.
The ecommerce implementation examples remain the same between the two May 2014 and April 2015 documents:
May 2014: Understanding SAQs PCI DSS V3
From graphic above:
“Prior to the release of SAQ A-EP, many e-commerce merchants with web sites that impacted the security of payment transactions may have felt they were eligible for SAQ A because their web server does not store, process, or transmit cardholder data. As a result, these web servers did not have sufficient security controls applied to them and have become common targets for attackers as a means to compromise cardholder data.
SAQ A-EP is intended to identify the controls needed to secure merchant web sites that control or manage the payment transaction, and reduce the likelihood a breach of the web site can be used to compromise cardholder data.”
Old V2 ecommerce Guidelines
PCI Security Standards Council E-commerce Special Interest Group published their PCI DSS (v2) ecommerce guidance in January 2013. It says:
“No option completely removes a merchant’s PCI DSS responsibilities. Regardless of the extent of outsourcing to third parties, the merchant retains responsibility for ensuring that payment card data is protected. Connections and redirections between the merchant and the third party can be compromised, and the merchant should monitor its systems to ensure that no unexpected changes have occurred and that the integrity of the connection/redirection is maintained.”
Monitor its systems to ensure that the integrity of the redirection is maintained? that no unexpected changes have occurred? Sounds inscope-ish to me.
Feb 2012: MasterCard on Hosted Payment Pages
MasterCard on Hosted Payment Pages
Guidance from DRUPAL
The good folks at Drupal have also done some SAQ comparison and have published a report with some great guidance for their customers. Actually the guidance is so good, it could be applicable to any e-commerce merchant or service provider.
CoalFire’s ISACA presentation from May 2014
Spreedly (payment solution vendor) Dec 2014 Guidance
http://blog.spreedly.com/2014/12/18/pci-dss-v3-0-for-online-merchants/#.VUfHqf9FDvU
Northcloud (ecommerce solution) Guidance Feb 2015
http://www.northcloud.com/pci-dss-3-0-changes-payment-providers/#comment-146
Ad below this line:
