Wednesday, August 27, 2014

Announcing: The 2015 PCI DSS Workshop

PCI DSS Workshop 2015
April 19 - 22, 2015  
Green Valley Ranch Resort, Spa and Casino
Henderson, NV (Las Vegas metro area)
The Treasury Institute for Higher Education is facilitating its annual PCI DSS Workshop. This program is geared toward business, financial, or IT manager responsible for PCI-DSS. The workshop will once again explore the unique PCI compliance challenges facing Higher Education institutions. As well as offer a deeper understanding of PCI, how institutions can achieve and maintain compliance, and the opportunity to make valuable new contacts with peers at other institutions facing the same challenges.


Please note that attendance at this program is
limited to representatives from colleges and universities only.

Tuesday, August 12, 2014

Higher Ed PCI Listserv

If you are a subscriber to the Payment Card Industry Compliance Discussion listserv, please be aware that there will be a change to the list address coming this week. You should see an announcement from the list in your Inbox soon.

You may need to change your anti-spam filters to keep the messages coming without interruption.

--Gene

Wednesday, August 6, 2014

Who Should Drive PCI DSS Compliance?

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

Whenever I talk to my colleagues around the country about who in their organization is responsible for managing PCI DSS compliance, I usually get two different answers -- either the technical security side of the organization or the business side.  Of course, the merchant is the responsible entity as far as the acquiring bank or the payment card associations are concerned but when there are multiple merchants in the organization there needs to be someone coordinating / managing the compliance effort.  So, who is in a better position to drive / manage the compliance effort?  (Or, as we say around here, who is responsible for herding the cats?)

There are good arguments for letting the technical security people drive the process:

  • They are closer to the actual technology used to process transactions at the merchant level.
  • They understand the security techniques used to secure the transactions (blinking lights and all).
  • They control the infrastructure through which transactions are processed (network, firewalls, phone lines, PCs, and so forth) -- or they have direct links to the people who control it.
  • They understand the techno-speak language in which the PCI DSS / PA-DSS is written, and, in particular, understand the objectives behind each of the standard's requirements.
  • PCI DSS compliance is a security thing and that is what they are paid to do.

You can probably add other reasons why PCI DSS compliance belongs on the technical side.

On the other hand, I feel that there are good arguments for making the business side of the house responsible for driving PCI DSS compliance:

  • They control the money, including funding for those parts of the security process that might need outsourcing (penetration testing, ASV scans, QSA assistance, and so forth).  And, in the event that remediation is required, they are generally the ones who have to figure out where to find the money, often on an emergency basis.
  • They already deal with multiple other compliance regimes in a lot of other areas; that experience can be directly applied to the PCI DSS compliance process.
  • The business side of the organization is already doing risk assessments in other areas and so can assist with the critical but non-technical aspects of PCI DSS risk assessments (in areas such as phishing, social engineering, broken processes, etc.).
  • They are already managing business risk trade-offs in other areas of the organization (particularly in treasury) and can apply that expertise to PCI DSS compliance -- particularly with respect to accepting risk or implementing compensating controls.
  • Treasury, in particular, speaks that really strange language that only bankers speak (ACH? settlement? OFAC? credits and debits?) and they manage the organization's relationship with the Acquiring Bank.  It is really that relationship that is driving the organization’s PCI DSS compliance efforts.  In addition, if a merchant account needs to be cut off, it is the business side that needs to work with the Acquirer to close out the merchant account.
  • They understand the larger context of the business and how all the moving parts, including payment acceptance, fit together.
  • They understand good business practices and procedures that should be in place in every merchant environment.

It is this last point that really convinces me that the business side (most likely Treasury) should be driving the compliance process.  God bless the technical security staff but they will secure whatever they are asked to secure -- including horrible business practices that should never have been allowed in the first place.

In reality, of course, neither side can have a successful compliance process without the other; it is a complex dance between partners with the goal of making each and every merchant secure through both best business practices and best technical security implementations.

Your thoughts on the issue?



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 PCI DSS 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 joe.tinucci@cu.edu)

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 joe.tinucci@cu.edu)

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 http://www.treasuryinstitute.org/pages/PCI-DSS-Workshop-2014.html 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!

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.