Thursday, July 10, 2014

A Few Thoughts on Liability

[This is a guest post from Joe Tinucci, Assistant Treasurer of the University of Colorado. --gaw]

The other day I met with some colleagues of mine from a nearby city which was covered under our joint state-wide governmental entity merchant services contract. They had several questions raised by their legal department about their obligations under the contract.  The main thrust of their questions and our subsequent conversation revolved around their liability, for both merchant activity and PCIDSS compliance, when they had completely outsourced their merchant processing to a third party.

Under the typical merchant services contract, the merchant of record is the responsible party -- for everything, including PCIDSS compliance.  You can try to limit your liability by outsourcing your processing to a compliant third party processor, but in the end they are simply acting as your agent and you still have liability for them.  This seemed to be a surprise to my colleagues, even though they had read the contract.

It is probably a good idea to take a few minutes to review your contract to confirm this issue.  If you read it carefully, you will probably not find much, if any, discussion of third party service providers -- everything is framed in terms of your responsibilities to submit valid transactions, of proper amounts, for legal goods and services, in accordance with the card association rules, and so forth.  In addition, your agreement likely requires you to indemnify the acquirer against any losses or liabilities arising from your service provider's actions or inaction.

You might also want to talk to your bank about being the merchant of record.  In our discussions with our bank, they have always indicated that the "merchant of record" is the responsible entity (as well as their client) for everything, including PCIDSS compliance.  If you are not the merchant of record, though, then it's not your problem -- at least according to our bank.  I'm not sure that is the entire story, however, as it is very possible to take a hit to your reputation even if a third party is the merchant of record but processing transactions for your customers (say, an online event registration site processing registrations for one of your departments).  

As can be inferred from the new SAQ A under version 3.0, even outsourcing everything to a compliant third party processer still requires:
  • Confirmation of service provider compliance with the PCIDSS, as well as ongoing monitoring of that compliance
  • Prohibition of the electronic storage of cardholder data
  • Physical security of any cardholder data which may be held on paper
  • Destruction of the cardholder data when no longer needed, if retained
  • A security policy in place that covers cardholder data security, management of third party service providers, written agreements with service providers, and specification from the service provider about which PCIDSS requirements they manage and which are your responsibility
The conclusion from our discussion and this line of thought -- it is extremely important that you thoroughly investigate any service providers before you trust them to handle your merchant activity.

Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships.  As part of that job, he also drives the PCIDSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses.  Joe can be reached at (303) 837-2185 or

Tuesday, April 29, 2014

Live from Chicago

Poor lodgings
Our hotel is nicer than this one.
Hi Folks!

I just wanted to check in from the 2014 Treasury Institute for Higher Education PCI DSS Workshop. I have to say that in my four years of attending this event, this year's program seems outstanding. We have had a number of great guest speakers and member-provided programs that show off the amazing talent and depth of knowledge this group possesses.

One theme that has been coming through this week is that there is no other event like this: a three-day workshop (or conference) focused on educating the attendees about information security and PCI DSS. The closest thing to this that I am aware of is the Community Meeting sponsored by the PCI Security Standards Council itself. And considering that we are not the authors of the standard, the higher education PCI compliance community can take a lot of pride in what we teach and share about our nuts-and-bolts, boots-on-the-ground experiences with trying to apply this standard in the most complex environments in the world.

We have heard for years that the unique environments of our college and university campuses are less like a merchant and more like a city full of diverse (and sometimes unruly) merchants when it comes to working with the PCI DSS. And most of us have far fewer resources to work with than a major retail, hospitality, or healthcare corporation. How do we do it?

Commitment. Teamwork. Knowledge. Communication. Sharing.

We have put into practice here and on our PCI Listserv a true Open Source Community in the classic sense. The private business sector could not duplicate what we do here every spring with our PCI Workshop. Can you imagine business rivals working together to share examples of how they conduct their operations? To encourage and help their competitors find the solutions that would keep them in business? To be open to engaging with their rivals to work together and share their corporate intellectual property and the results of their years-long research projects? It's a stretch for me to think of something like that, but it is what we do here intensely for three days every spring and what we do day-in and day-out on our listserv and in e-mails and phone calls to one another.

You know, we're not the ones who came up with the idea of putting unencrypted credit account data on a magnetic stripe stuck to the back of a piece of plastic. We didn't build the systems that can be used to easily steal that data from computers and networks, and then duplicate the cards in order to steal money from innocent victims. An we're not the ones who said "Oops, we better fix that with these 286 security requirements that we'll make merchants who are already broke prove they can meet, every single day without fail. No prior knowledge of InfoSec required." I know none of you thought up this situation. (Although I often get blamed for it.)

But each day we rise to the challenge of PCI DSS compliance and say, "OK. Bring it on!" I'm really proud of all of us here. For me, you guys make my success in my job possible. You challenge me and make me think of how to solve my problems in whole new ways. I am so grateful that I get to meet with you all every year and soak up your energy and optimism.

Thank you Treasury Institute for Higher Education. Thank you PDG and Katy. Thank you Dennis, Ron, and all of you who came from schools spread out from Florida to Alaska. And thank you, Walt Conway, for bringing everything you had to build this workshop into what is has become. I hope we have been able to honor you, in gratitude for what you gave to us. I hope you are also proud of what we have been able to do here this week. We'll remember you always.

Tuesday, April 22, 2014

2014 PCI DSS Workshop - Still Open

Bob Russo
There are still some remaining spaces left if you want to attend the 2014 Treasury Institute PCI DSS Workshop. Go now to for more information and to register today.
We have a terrific lineup of presenters and programs this year, with sixteen program sessions, several of them targeted specifically toward each of our main attendee groups: a Business Track and a Technical Track. Our general sessions include industry experts who will speak on threat analysis, data breach response, PCI DSS v3.0 in Higher Education, and our always popular expert panel. And once again we will gain insights directly from the Council, as Bob Russo, General Manager at PCI Security Standards Council, will be with us to talk about PCI DSS 3.0 and Business as Usual.

So please join us next week in Chicago at the historic Palmer House Hilton if you can. You don't want to miss this one!

Palmer House Hilton, Chicago, IL
The Palmer House Hilton in Chicago, Illinois

Monday, March 10, 2014


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,

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,

PCI DSS v3.0

Thursday, February 20, 2014

PCI DSS and PA-DSS Now in Nine Languages

WAKEFIELD, Mass., 20 February, 2014 —Today, the PCI Security Standards Council (PCI SSC), an open global forum for the development of payment card security standards, announced that the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS) 3.0 are now available in nine languages. Organizations worldwide can now benefit from increased understanding of PCI Standards in their native language.

PCI DSS and PA-DSS 3.0 were published in November 2013, with updates made based on feedback from the Council’s global constituents and response to market needs. More than 50% of this feedback came from outside of the U.S., emphasizing the Council’s active international membership base. Version 3.0 helps organizations worldwide make payment security part of their business-as-usual activities by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility.
The PCI SSC website supports translated pages and PCI materials including the new PCI DSS v3.0 and PA-DSS v3.0 in the following languages: Chinese, French, German, Italian, Japanese, Portuguese, Russian and Spanish.

See the full news release here: