Re: PCI - Third party vendors

[Robert Lau <Robert.Lau () USC EDU>]

When there is a breach…  in addition to the negative publicity, you will lose the trust of your students, faculty and 
staff because as Peter said, they bought their coffee at your university. Granted, our customers are more captive than 
Target’s, but the blowback is just as painful. They will ask questions like “You knew that vendor wasn’t safe but yet 
you still let us buy from them?” Deflection of responsibility, however legally sound, will not suffice.

Even if there are no lawsuits, even if Mastercard does not demand an audit, the reputation of all involved (netadmin, 
security, legal, etc.) is tarnished.

We put in a lot of effort to ensure that 3rd party vendors, even ones that are here for only a few hours, are properly 
segmented and secured if they use our network. Cellular or POTS is preferred.

-robert


From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Peter 
Setlak
Sent: Friday, July 25, 2014 10:14
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] PCI - Third party vendors

Mike, good point. If you accept Visa or MC, at some point, you signed something with someone that said you will 
(reasonably) comply no matter how fine the print was.

It is always key to remember that the PCI-DSS standard extends beyond the technology and into the land of paper... A 
great way for a merchant to protect their customer's CHD is to use terminals that encrypt the data upon swipe (or key 
entry) and transmits the data directly to an acquirer; however, this simple gesture alone does not make the merchant 
compliant. The merchant must also ensure (through policy, usually), that they perform ALL credit transactions in this 
manner (or another secure manner). For instance, if I take donations over the phone and write down the CHD so that it 
may be processed (keyed-in) at the terminal later, and I take little or no reasonable action to protect that CHD before 
keying it in or to destroy it after I'm done, I am out of compliance. If I have a policy (and demonstrate that I follow 
it) that states I do not accept CHD over the phone, that I only accept "card-present" transactions that are swiped 
directly into my (approved) terminal that is connected via POTS to my acquirer, and that acquirer is listed as 
compliant with the PCI council, then I should be compliant.

Craig, while you're not obligated to be PCI compliant in this case, your best bet is to get terminals that dial-out 
directly to the acquirer and bypass your network all-together. If you provide infrastructure for "ABC Coffee"'s 
transactions, and they decide to follow their PCI contractual obligations (and you decide to accommodate their needs), 
you may end up having to make some major network changes including additional network segregation, SPI firewalls, 
config and access auditing/logging, 802.1x implementation for their terminal, etc, etc. I mean, not that you shouldn't 
already be doing these things but if you're not and you're not ready to get there yet or you find that the expense to 
do so far-outweighs the income/risk to the coffee shop then...

Just my two cents, if a 3rd-party on our campus was to ask for network access so they could perform transactions and 
they didn't ask their infrastructure provider for these things (they may be asking for them in their contract, beware), 
I'd seek out a different vendor. As far as the coffee shop's customers are concerned, they bought their refreshments at 
the university library, not "ABC Coffee". If ABC Coffee is compromised because they were going over an under-secured 
infrastructure, whose name will make the papers?


On Fri, Jul 25, 2014 at 11:24 AM, Mike Chapple <mchapple () nd edu<mailto:mchapple () nd edu>> wrote:
Blake,

Respectfully, I disagree with the conclusion that you've reached.

The important point is that PCI DSS is a contractual obligation, not a law.  The only way that you can become subject 
to a contractual obligation is to voluntarily accept it by signing a contract.  If it were true that "Any entity that 
processes, stores, or transmits CHD must comply with the standard," it would be forcing entities who are not a party to 
the contract (merchant agreement) to comply with the terms of that agreement.

Under this logic, I could take a file of credit card numbers and stick it in Dropbox and that would make Dropbox a 
service provider subject to PCI DSS.  That is not the case, as Dropbox never agreed to handle credit card information 
for me under the PCI DSS standard.

That said, it is clearly the responsibility of the merchant to only use service providers who agree to comply with PCI 
DSS.  The contracts they have with those service providers should include language to that effect, thereby transferring 
some compliance obligations.  Absent that language, it is the responsibility of the merchant to not use that particular 
service to transmit unencrypted CHD.

Just my two cents.  I'm not a lawyer :)

Mike


On Fri, Jul 25, 2014 at 10:54 AM, Blake Penn <BPenn () trustwave com<mailto:BPenn () trustwave com>> wrote:
Craig,

The fact that they are an external entity does not obviate your PCI DSS compliance.  Any entity that processes, stores, 
or transmits CHD must comply with the standard.  The nuance here is that you don’t have an associated MID (since they 
are a third party) and therefore no associated acquirer relationship/contractual compliance obligations.  This changes 
your *enforcement/validation* requirements (there are none) but not your actual *compliance* requirements.  The way the 
card schemes see it is that CHD is their data and anyone touching it must comply with the DSS (how they would enforce 
this view is an entirely different matter).

That being said, your QSA should be able to come up with controls that may minimize (or perhaps eliminate) the scope of 
your compliance burden.  The easiest way compliance-wise is to avoid the issue, though.  I commonly see clients set up 
a separate physical network routed out to the ole’ Interwebs through a cheap consumer-grade DSL/Cable connection for 
guest wireless and other such use.  That way the networks never touch (“Don't cross the streams.”) and compliance 
really doesn’t become an issue.

Hope that helps.  Do consult with your friendly neighborhood QSA, though, for specific guidance on this issue.


Blake Penn  CISSP, PCIP, MCSE, MCSD, MCDBA, QSA, ISMS Principal Auditor
Principal Consultant
t: 678.685.1277<tel:678.685.1277>

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

DISCLAIMER: The views represented in this message reflect the personal opinions of the author alone and do not 
neccessarily reflect the opinions of Trustwave.


From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () 
LISTSERV EDUCAUSE EDU>] On Behalf Of Drake, Craig
Sent: Thursday, July 24, 2014 4:30 PM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: [SECURITY] PCI - Third party vendors

We have a new coffee shop going into our library.  They are completely run by an external entity not associated with 
the university.  They want to connect their terminals to our university network (possibly wireless) to transmit their 
credit card transactions.  What do we need to be concerned with in terms of PCI compliance with them running this 
through our networks?

Thank you,
-Craig

Craig Drake

University Technology Services
Northeastern Illinois University
5500 North St. Louis Avenue, Chicago, IL 60625
Phone: (773) 442-4386<tel:%28773%29%20442-4386>
Email: C-Drake () neiu edu<mailto:C-Drake () neiu edu>

www.neiu.edu<http://www.neiu.edu>


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under 
applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If 
you received this transmission in error, please immediately contact the sender and destroy the material in its 
entirety, whether in electronic or hard copy format.



--

Best regards,
Mike

Mike Chapple, Ph.D.
Senior Director for IT Service Delivery
Concurrent Assistant Professor, Management
University of Notre Dame
236 IT Center  |  Notre Dame, IN 46556
P: 574-631-5863<tel:574-631-5863>  |  M: 574-274-0151<tel:574-274-0151>
mchapple () nd edu<mailto:mchapple () nd edu>







--
Thank you,

Peter J. Setlak
Network Security Analyst, GSEC, GLEG, GCPM
Colgate University
---
psetlak () colgate edu<mailto:psetlak () colgate edu>
(315) 228-7151
Case-Geyer 450

Colgate IT Security - http://colgate.edu/itsecurity

Think Green! Please consider the environment before printing this email.

Engage with Colgate University:
News blog<http://blogs.colgate.edu/>, Twitter<https://twitter.com/#%21/colgateuniv>, 
Facebook<https://www.facebook.com/colgateuniversity>, Google+<https://plus.google.com/u/0/b/113333907606560373469/>, 
Delicious<http://www.delicious.com/colgatenewsmakers>, YouTube<http://www.youtube.com/cuatchannel13>, 
Flickr<http://www.flickr.com/photos/colgateuniversity/>, Pinterest<http://pinterest.com/colgateuniv/>, 
LinkedIn<http://www.linkedin.com/company/colgate-university/>