Monday, March 10, 2014

Sneaky!

sneaky guy
I have been thinking about one of the new SAQs, SAQ B-IP (Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage), and wondering about how and where it might fit in to my card processing environment or the environments of other Higher Education operations I know of. I had made a brief survey of it to write an introductory post, First Look at the New SAQs: Evolution, and I planned on digging into its depths as soon as time permitted.

Meanwhile, back at the day job, this morning I was checking on PTS validation status of a product and found an interesting link I hadn't noticed before. And what do you know? In the PCI SSC documents library I noticed that three new documents were published in February and early March covering PTS POI devices and the related approval program. Usually new publications show up on the PCI SSC home page, but not in this case.

I will be taking a look at these documents before I write more on SAQ B-IP.

Monday, March 3, 2014

First Look at the New SAQs: Evolution

[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.

PCI SSC Releases Version 3.0 Supporting Documents

Over the last several weeks the PCI Security Standards Council (PCI SSC) has released many of the documents that support the new version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS). These documents may be accessed in the Documents Library of the PCI SSC web site, https://www.pcisecuritystandards.org/.

Version 3.0 of the standards certainly is another evolution rather than a revolution. If you start reading version 3.0 you aren't going to be shocked. It does have a different look. The check-boxes are gone since version 3.0 is no longer doing double-duty as the reporting template for the Report on Compliance, or ROC. That space has been filled with content from the Navigating PCI DSS, which will no longer be a separate document. I think that is a great idea, because now I don't have to go back and forth between two lengthy docs to grok all of this deeper PCI DSS meaning. But for a quick overview of what's new in the new standard, I strongly recommend going through the PCI DSS Summary of Changes v2.0 to v3.0. Then you will have a good idea of what to expect when you start reading the standard.

The first of the new supporting documents, and one which is sometimes overlooked, is the Glossary of Terms, Abbreviations, and Acronyms v3, released in January of this year. The Glossary is one of my go-to documents to make sure I don't confuse the common meaning of a term with the exact meaning that applies in the context of PCI compliance. There are additions, changes, and removals as new terms come in to replace some older ones. I'll try to do a write-up on the glossary sometime soon.

In February, it literally rained supporting documents. First we saw a number of documents used by the Assessment community, our QSAs and ISAs. There is a new publication called the ROC Reporting Template for v3.0, which replaces the section Instructions and Content for Report on Compliance in PCI DSS v2.0 and the document ROC Reporting Instructions for PCI DSS v2.0. Other documents used by ISAs and QSAs after completing an onsite assessment and preparing the ROC are the Attestations of Compliance: PCI DSS AOC - Merchants v3.0 and PCI DSS AOC - Service Providers v3.0.

OK, what about us merchants out here? I understand that the assessors need first crack at this material, but we are the folks that need to manage our businesses and keep current with the compliance requirements. Well, last Friday was my day, it was SAQ-apalooza! And this time it was not four, not six, but NINE new Self-Assessment Questionnaires that were released for us to dig into. We still have our four, standard SAQs: A, B, C, and D. SAQ D is now split into two separate versions, one for Merchants and one for Service providers, which eliminates the optional "if you are a service provider blah, blah, blah" questions. The younger kids, SAQ C-VT and SAQ P2PE-HW are decked out in their shiny-new v3.0 formats.

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 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.

Due to time limits, I will leave discussion of those new SAQs for tomorrow.

PS:Don't forget to sign up for the Treasury Institute's PCI Workshop at the end of April! See the sidebar for information and links.

More things to read:
All of these new documents and more are available in the PCI SSC documents library, https://www.pcisecuritystandards.org/security_standards/documents.php.

PCI DSS v3.0
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf