Re: PCI compliance question

[Joel Rosenblatt <joel () COLUMBIA EDU>]

Your assumption here is that the University IS a merchant .. let's say that the University does not have any relationship with any branded CC (no MIDs at all) 
.. then to say that the student swiping their CC in a machine that doesn't accept CCs puts the University at risk for a PCI violation makes no sense at all.

The vending machine is not associated with any MID, therefore the problem is not a PCI problem -- it is a data security 
problem.

If someone sends me an email with a CC number in it, and I don't have anything to do with CCs, does my desktop become a PCI liability - I don't think so.  But 
I do have data that I shouldn't have.  The right thing to do is to delete the data, not call up a QSA and have my mail audited, or have a ASV scan all of my 
desktops because somewhere it them may be a CC number.

I do understand your points, and they may be valid under certain conditions - but in this case, I don't think so.

It would help if the original poster (Bob Smith) would clarify some of the conditions - that way we could maybe really 
answer his question :-)

My 2 cents

Joel

--On Friday, July 09, 2010 9:11 AM -0500 Paul Kendall <PKendall () ACCUDATASYSTEMS COM> wrote:

> Let's examine the POSSIBLE information flow here. The consumer swipes a branded credit card in the vending machine. I 
> would assume the vending machine is
> transmitting at least some of the magnetic stripe data to the server. What exactly that consists is unknown at this time but 
> let's assume it's all of track 1
> data.  The question then becomes "what is the University's backend system doing with this data during its determination 
> process to see if it's a university
> card or something else?"  If the data lands in a database and is then checked and as a result rejected because it's not 
> a university card...this is a
> problem, and the system should be considered in scope.  If it's in RAM and then validated, then there are still 
> concerns over this approach but it is more
> likely to be able to state that  the university is doing what it can to avoid receiving such data and the system COULD 
> POSSIBLY be considered out of scope.
> Without knowing the exact verification mechanism, it is difficult to say how the university should handle this.
>
> In this case, it is the consumer that is acting outside of the normal payment process. PCI does not apply to the 
> consumer, but only to the merchant who
> transmits, stores, or processes cardholder data. It would be preferable to configure the vending machine firmware to 
> accept/reject the card number based on
> the BIN value (BIN value is the first six digits of the card that identify the issuing bank) at the machine itself. 
> While this would likely require firmware
> upgrades on the vending machine itself, rejecting the number at the source will effectively reduce the scope and should 
> be sufficient to consider the back
> end servers out of scope.
>
> Paul
> ========================================
> Paul L. Kendall, CGEIT, CHS-III, DHS-CVI, CISM, CISSP, CSSLP
> PCI Qualified Security Assessor
> Senior Consultant
> Accudata Systems, Inc.
> 15305 Dallas Parkway, Suite 300
> Dallas, TX 75001
> (817) 496-6450 Fort Worth Office/FAX
> (281) 897-5000 Corporate Office
> (281) 897-5001 Corporate FAX
> (713) 446-5259 Cell
> http//www.accudatasystems.com
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Daniel 
> Robert Adinolfi
> Sent: Friday, July 09, 2010 8:30 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] PCI compliance question
>
> On Jul 08, 2010, at 14:57, Joel Rosenblatt wrote:
>
> > If you are not accepting CC, then the fact that the miss guided person sticks his card in your device does not put that 
> > device in scope for PCI.
>
> Our read on this issue mirrors Joel's.  Though, I agree with another poster (sorry, I lost that message) who said they 
> put signs on the vending machines that
> say "This machine will not accept credit cards."
>
> Based on our fun experience with a QSA during a gap analysis we asked for, documentation is really, really important.  
> If something is documented, it exists.
> If it is not documented, it does not exist to an auditor.  Therefore, document where you take credit cards and where 
> you do not.  If a unit has a card
> reader, their PCI documentation should include that fact and describe that that they do not write down the card 
> number/accept them on post-it notes on their
> front door/allow someone to write it down in magic marker on an office plant/etc.  (It's probably easier to say, "We 
> ONLY accept cards in the following
> ways".)  Make these policies clear to the public, and you have gone a long way to limit your exposure.  Document, 
> publish, and stick to the documentation.
>
> So, back to the question, if you put signs on your vending machines that say "Don't be silly and use a credit card here.  
> We'll laugh at you.", document that
> in your Big Book o' PCI Documentation, and make sure your application cleans our any errant CC data that might touch it, you 
> don't need to consider that
> system in-scope.
>
> My $0.04.  (inflation)
>
> -Dan



Joel Rosenblatt, Manager Network & Computer Security
Columbia Information Security Office (CISO)
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel