[Apologies, I didn't get this published as soon as I hoped I would.]
OK, now where were we? Oh yes, the new Self-Assessment Questionnaire (SAQ) types.
And then we have the new guys: SAQ A-EP and SAQ B-IP. What are these all about? The Council recognizes that payment systems are evolving and they are not nearly as simple as they once were. (Who remembers the first one-size-fits-all SAQ, with 75 total questions?) The new SAQs highlight this idea of evolution in two distinct ways.
Let's start with the cooler one of the two, SAQ B-IP.
SAQ B-IP seems to fit the evolution description to me. Its cover page description says it's for
Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage. Uh-what? I think I need to parse this slowly.
First of all, it's for a
standalone device. It's
IP-connected. This reminds me of SAQ C, but evolved. SAQ C is for "Payment Application Systems Connected to the Internet," and SAQ B-IP is for "PTS Point-of-Interaction (POI) Terminals." This sounds like a card swipe terminal that has evolved into something more advanced. These devices must be validated as
PCI PIN Transaction Security (PTS) Point of Interaction (POI) devices.
The PTS is now rolled up with some other hardware requirements into the
Point of Interaction (POI) Modular Security Requirements v4.0. Here is an excerpt from that document.
The purpose of this document is to provide vendors with a list of all the security requirements against which their product will be evaluated in order to obtain Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) device approval.
Version 3 introduced significant changes in how PCI will be evaluating PIN and non-PIN acceptance POI terminals. PCI no longer maintains three separate security evaluation programs (point-of-sale PIN entry device (PED), encrypting PIN pad (EPP), and unattended payment terminal (UPT)). Instead PCI provides and supports one set of modular requirements, which covers all product options.
To qualify to use SAQ B-IP you must therefore use these more specialized devices, which have passed the PTS program tests, to take your customers' payment card information. There are several other conditions to meet, including isolation from other systems and no connections to computers, mobile phones, tablets, etc. This is very specialized hardware, folks. My guess is that these things cannot be part of a centrally-managed, multi-terminal POS system.
Now, for SAQ A-EP. I think this one is more a matter of playing catch-up, it's an evolution in the
interpretation of the standards rather than a new technology. As I mentioned in my previous post,
On the Eve of PCI DSS 3.0: Scope Creep, Visa and MasterCard have been itching to tighten down security for certain types of e-commerce environments. We saw this from the PCI Council in the Information Supplement
PCI DSS 2.0 eCommerce Guidelines, released in January 2013. And we heard the message in the PCI Scoping session at RSA 2013 from Lauren Holloway and Emma Sutcliffe of the PCI Council. This issue was discussed in the technical sessions with Walt Conway at the 2013 Treasury Institute PCI Workshop. It was laid out clearly for assessors at the 2013 PCI SSC Community Meeting. And it was printed in black and white in
PCI DSS v3.0, Scope of PCI Requirements: "web redirection servers" are in scope.
So we all knew this was coming, but we still didn't know exactly what it meant. I kept hearing and seeing this phrase, or something like it,
"it is recommended that merchants implement applicable PCI DSS controls
as needed to ensure the security of the website." But what exactly were these
"applicable PCI DSS controls" they referred to? I think the best answer I got was, "the controls that apply in your particular environment." Well, there's a whole heap o' helpful. But now we have the answer to the
"Which controls?" question: Use SAQ A-EP.
I started to read through SAQ A-EP as soon as I saw it on the PCI SSC web site. One of the first things I noticed is that it encompassed all 12 PCI DSS requirements. As a matter of fact, I counted 139 questions. That's more than SAQ C!
Then I looked at the qualifications, contained in the
Before You Begin section.
SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.
This is just what we are doing at my university. We have a third-party processor that handles processing for us in two different ways. If we want to use their fully-hosted system we can set up a complete store using a web-based management tool. This works very well for campus units that have simple processing needs. They want to sell documents or genetic material, handle conference registrations, soil-sampling services, etc. This type of unit reports compliance with SAQ A, and that won't change. But if the unit has more a complex sales model they may use their own web application or specialized shopping cart on their university server, and then they pass the customer off to a payment processing page hosted by our vendor. This is what SAQ A-EP was designed to cover.
Following from the
PCI DSS 2.0 eCommerce Guidelines and PCI DSS v3.0,
both our merchant's systems and our processor's systems can affect the security of card data, so they are now both part of the Cardholder Data Environment. Rather than validate compliance with SAQ D, we can use SAQ A-EP if we validate under PCI DSS v3.0 and if we meet the following nine qualifications:
- Your company accepts only e-commerce transactions;
- All processing of cardholder data is outsourced to a PCI DSS validated third-party payment processor;
- 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);
- If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);
- All elements of payment pages that are delivered to the consumer’s browser originate from either the merchant’s website or a PCI DSS compliant service provider(s);
- Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;
- Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
- Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
This is a fairly tight set of qualifications, and it raises a question for me. What if we have two separate processing environments, wherein we handle both e-commerce and MOTO (Mail Order/Telephone Order) transactions, and process the MOTO sales using a card-swipe terminal connected to an analog phone line (a SAQ B environment?) The standard answer, from the PCI SSC
FAQ 1082, is that if you qualify for more than one SAQ, then you should use the more stringent SAQ to cover both. That is usually the one higher up the alphabet. But SAQ B would not cover it
at all for an e-commerce CDE. And SAQ A-EP does not contain all the requirements in SAQ B. So does that mean SAQ D, with a whole bunch of N/A answers, along with documentation explaining why those answers are N/A? That would be a very cumbersome way to validate compliance. FAQ 1082 was last updated March 13, 2009 and it's time for an update. I have submitted this question to the PCI SSC
Frequently Asked Questions site to see if they will amend the current FAQ answer for today's more evolved payment environments.
That's it for this post. A future post will look at the content of these new SAQs and how they fit into the PCI DSS v3.0 world.
Posts
