Re: PCI compliance question

[Paul Kendall <PKendall () ACCUDATASYSTEMS COM>]

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