Re: PCI - Third party vendors

[Peter Setlak <psetlak () COLGATE EDU>]

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> 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.
>
>
>
> --
>
> 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  *|*  *M: *574-274-0151
> mchapple () nd edu



-- 
Thank you,

Peter J. Setlak
Network Security Analyst, GSEC, GLEG, GCPM
Colgate University
---
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/>