The SAQ-A-EP Apocalypse
The PCI SSC recently announced the new PCI DSS v3.0 Self Assessment Questionnaires (SAQs). Of particular interest was SAQ-A-EP, that has enshrined Visa Europe’s original guidance on securing Hosted Payment Pages (HPPs) into PCI DSS v3.0.
This of course is a great move for card data security as a whole, but generally bad news to merchants whom thought they could vastly reduce their PCI DSS footprint by opting for HPPs.
As a brief recap, HPPs are third party pages that are embedded in a Merchant’s website for the purposes of taking card payments. What a customer enters into their browser is entered directly into the third party’s payment page and avoids the Merchant’s website altogther, thus allowing the Merchant to validate using SAQ-A, which is a very basic SAQ with 13 questions in it. At least that is, until now.
SAQ-A-EP is a game changer. There are now 100+ technical controls to validate for ANY Merchant that uses a hosted payment page, and there must be millions of hosted payment pages out there that now all require a Merchant’s web environment to be:
- Properly segmented, with a stateful firewall
- Configured security, with documented config standards
- Searched for Sensitive Authentication Data
- Installed with an up to date anti-malware solution
- Part of a Merchant’s vulnerability management programme
- Subject to strict Change Control and Secure Software Development Lifecycle
- Developed inline with OWASP / SANS or similar
- Accessed only by authorized personnel
- Accessible remotely by two factor authentication only
- Physically secured
- Audit logged
- Vulnerability scanned for missing patches
- Penetration tested
- Installed with File Integrity Monitoring (FIM) – although this has been watered down a bit now, a post to follow.
- Covered by an Information Security Policy and Awareness Programme
The real danger here is that smaller Merchants using HPPs simply won’t be aware of the above changes. Without anyone telling them, they’ll quite happily validate using SAQ-A until the cows come home.
An onus needs to be put on providers of hosted payment pages to ensure that all their clients are validating using the correct methods, or alternatively uplifted to a fully managed e-commerce platform/solution, as quite frankly, a SAQ-A-EP in the hands of some guys selling shoes out of their garage is a ticking time bomb.
Yet again, the PCI SSC have excelled in producing a fantastic standard – it’s faultless! The trouble is, once customers, resellers and hosted-payment page providers try to implement this, and roll out to a million Merchants worldwide that are using HPPs (by December 31st, 2014), something is just going to go wrong.
If you know any Level 4 merchants that are using hosted payment pages, please feel free to send them this blog post. If their reply is “WTF is this guy going on about?”, then that’s exactly what I expect, and exactly why application of this otherwise flawless standard is doomed.
Visa, MasterCard, Amex, Discover, JCB – please take credit cards away from people that don’t know how to secure them. Don’t ask them to get technical – it doesn’t work!
UPDATE 28 APRIL 2014
Another way to look at this is that any e-commerce payment method that means card data touches a merchant’s system, has always been in scope for SAQ-D.
The problem the community faces is misinterpretation and inconsistent guidance. Hopefully SAQ-A-EP will make people think twice, and perhaps remind them that their systems have always been in scope for SAQ-D, and SAQ-A-EP should help them.
But until the card schemes and acquiring banks make their minds up as to what types of HPP fall under SAQ-A-EP scope, the community should not yet be applying SAQ-A-EP to their environments, but be conscious that it will become mandatory January 1st 2014.
If in doubt, then SAQ-D in the meantime, or seek a professional QSA’s advice.