Re: PCI - Third party vendors

[Mike Chapple <mchapple () ND EDU>]

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>
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
> <%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> 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
> > 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