Re: PCI - Third party vendors

[Theresa Semmens <theresa.semmens () NDSU EDU>]

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
F: 701-231-8541
E: Theresa.Semmens () ndsu edu
www.ndsu.edu/its/security

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Oscar 
Knight
Sent: Friday, July 25, 2014 10:54 AM
To: 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>  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
> >
> >
> >
> > *Trustwave* | SMART SECURITY ON DEMAND
> >
> > 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] *On Behalf Of *Drake, Craig
> > *Sent:* Thursday, July 24, 2014 4:30 PM
> > *To:* 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
> > Email: 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.


--
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
Appalachian State University, Boone, NC 28608        FAX: 828-262-2236