Educause Security Discussion mailing list archives
Re: PCI - Third party vendors
From: David James Anderson <David.Anderson () NAU EDU>
Date: Fri, 25 Jul 2014 16:58:18 +0000
Agreement with the legal waters bit. I’ll still add what we found in our experience so far with PCI compliance so far in conjunction with our QSA. We have similar operations going on with a third party operating foodservice venues within our campus buildings and network. For our compliance status, it came down to who owned the merchant IDs. In essence, our goal is to be able to accurately and truthfully fill out SAQ’s for all of the bank merchant IDs that we own and have them signed off on by our QSA. We found that in this case the third-party vendor owned the merchant IDs for these food venues. This means that we would not be filling out SAQ’s for these merchant IDs, since we have no ownership or claim to them. That being said, we decided to continue our approach in securing those network and operational segments as if we did have full ownership and liability of the merchant IDs. Under PCI terminology, we fall under the role of a “Service Provider” to that vendor by hosting networking services for some of their PCI environment. If that vendor decided to fill out SAQ’s for those merchant IDs, they would be required to request our attestation of PCI compliance as a service provider and if we wanted to be able to respond to that positively, we would need to be up to the same specifications as if we had ownership of the merchant IDs ourselves. We are placing efforts in be prepared for when that time comes, and when we are ready to attest compliance as a service provider, will encourage our vendor to achieve and attest to their compliance as well. Hope this helps, -- -David. David Anderson Information Security Analyst, Senior Information Technology Services Northern Arizona University (928) 523-1225 On Jul 25, 2014, at 9:43 AM, Mike Chapple <mchapple () ND EDU<mailto:mchapple () ND EDU>> wrote: That's a very important point, Joel. No matter who is responsible from a contractual perspective, it is the big-name institution that will be in the newspaper headline. Mike On Fri, Jul 25, 2014 at 12:42 PM, Joel L. Rosenblatt <joel () columbia edu<mailto:joel () columbia edu>> wrote: +1 The general rule is that if you don't own the MID, it's not your problem - that doesn't mean that you may not get blowback in the way of reputational damage, but the banks can't come after you. IANAL Joel Joel Rosenblatt, Director Network & Computer Security Columbia Information Security Office (CISO) Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033<tel:%20212%20854%203033> http://www.columbia.edu/~joel Public PGP key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90BD740BCC7326C3 On Fri, Jul 25, 2014 at 12:28 PM, Theresa Semmens <theresa.semmens () ndsu edu<mailto:theresa.semmens () ndsu edu>> wrote:
I concur with Mike and Oscar. You are treading into legal waters - best to bring your lifejacket (general counsel) when doing that. Theresa Theresa Semmens, CISA NDSU Chief IT Security Officer Office: 210D IACC Mail: NDSU Dept 4500 PO Box 6050 Fargo, ND 58108-6050 P: 701-231-5870<tel:701-231-5870> F: 701-231-8541<tel:701-231-8541> E: Theresa.Semmens () ndsu edu<mailto:Theresa.Semmens () ndsu edu> www.ndsu.edu/its/security<http://www.ndsu.edu/its/security> -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>] On Behalf Of Oscar Knight Sent: Friday, July 25, 2014 10:54 AM To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU> Subject: Re: [SECURITY] PCI - Third party vendors Exactly, "PCI DSS is a contractual obligation". I assume none of us are lawyers, neither are QSAs. If there is a risk and in particular a risk with respect to a contract then you should contact university counsel. Oscar On 7/25/2014 11:24 AM, Mike Chapple 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/><http://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.-- NOTE: ASU ITS will NEVER ask you for your password in an email! Oscar D. Knight knightod at appstate dot edu ITS Voice: 828-262-6946<tel:828-262-6946> Appalachian State University, Boone, NC 28608 FAX: 828-262-2236<tel:828-262-2236>
Current thread:
- Re: PCI - Third party vendors, (continued)
- Re: PCI - Third party vendors Shamblin, Quinn (Jul 25)
- Re: PCI - Third party vendors Bruce Curtis (Jul 29)
- Re: PCI - Third party vendors Blake Penn (Jul 25)
- Re: PCI - Third party vendors Mike Cunningham (Jul 25)
- Re: PCI - Third party vendors Blake Penn (Jul 25)
- Re: PCI - Third party vendors Mike Chapple (Jul 25)
- Re: PCI - Third party vendors Oscar Knight (Jul 25)
- Re: PCI - Third party vendors Theresa Semmens (Jul 25)
- Re: PCI - Third party vendors Joel L. Rosenblatt (Jul 25)
- Re: PCI - Third party vendors Mike Chapple (Jul 25)
- Re: PCI - Third party vendors David James Anderson (Jul 25)
- Re: PCI - Third party vendors Mike Cunningham (Jul 25)
- Re: PCI - Third party vendors Peter Setlak (Jul 25)
- Re: PCI - Third party vendors Robert Lau (Jul 25)
- Re: PCI - Third party vendors Blake Penn (Jul 25)
- Re: PCI - Third party vendors Aube, Jane M. (Jul 25)