Re: OT TAN: POS Data Mining (was Re: Google at the Pump?!)

Scott in SoCal wrote:
On Sat, 10 Nov 2007 00:16:59 -0500, "Murderous Speeding Drunken
Distracted Driver (Hector Goldstein)"
<drunk_and_distracted@xxxxxxxxxxxxx> wrote:

Scott in SoCal wrote:

Thanks for the explanation.

No problem. I learned about it 9 months ago when I helped to bring
about 600 sites to PCI compliance. It was very interesting to observe
the architectural changes around the entire system (which had data
capturing/mining as one of it's design goals) in order to obtain that
compliance. Interestingly enough, before the upgrade, I had indirect
access to thousands, if not hundreds of thousands, of credit card
transaction details. Now I can't touch them. That is the only data
acquired from the field that I can't get to.

So without violating any NDAs, what data CAN you access? And how do
you (or the PCI) verify compliance? Specifically, how do you insure
that some sneaky programmer for some grocery store chain doesn't slip
in a back door to siphon off that oh-so-valuable track 2 data and
stash it someplace that you don't know about?

Basically you can't access any data on the card. Part of compliance is
that the data be encrypted as it's scanned, and that it remain
encrypted until it reaches the clearing house. Pretty much we get a
transaction ID and a pass/fail code from the clearing house as a
result of our submission, which is what we're allowed to store. :-)

Remaining compliant involves regular audits.

Prevention of security breaches sneaky by programmers, however, is a
different issue than what can be done by retailers with track 2 data.
In that regard, it would depend on how well the POS vender had done to
secure the flow of information from the point of scan to the point
it's submitted to the clearing house, as well as how secure the
underlying transport mechanisms are. Other concerns are SOX, so
there's more of an incentive to do business with publicly traded
companies. Even if I wanted to find a point to attempt to access the
data, I'd be raising some flags with the security group. :-)

Though anecdotal and totally unrelated, I performed a minor upgrade to
the credit card processing systems at about 450 sites yesterday. :-)

And it went off without a hitch? AT&T should hire you to upgrade the
software in their phone switches. :)

Worst failure rate to date is about 30 out of 520 upgrades, and it was
for a dicey project I really didn't feel like I was ready for, due to
it's complexity and the high risk involved. Fortunately none of those
fails took the respective sites down (and we're comfortable leaving
those 30 failed until I can get time to go back and fix 'em, as I've
got too much other work to do.) Other than that, I hit 100% on my
installs/upgrades.

The failure rate of the installed/upgraded components is a different
issue altogether, although mostly successful there as well. I have had
1 100% failure in that arena. :-/

Sounds encouraging, but then again Visa and MasterCard also have
merchant agreements that are violated all the time, and Visa/MC don't
seem to enforce their own rules very vigorously. In fact, it was just
such a violation that allowed hackers to steal all those credit card
numbers and other customer data frmo TJ Maxx:

http://www.msnbc.msn.com/id/8294175/

But the data wasn't stolen from TJ Maxx; it was stolen from
CardSystems. The only part the retailer had in this was their
selection of clearing houses.

OK, but the fact remains that SOMEONE wasn't following the rules and
was keeping data around longer than they were supposed to, exposing
that data to risk.

Agreed. But this discussion, I thought, was centered around what
retailers can track with credit card data. The only information
regarding a purchase that is submitted to a clearing house is the
purchase amount, not the items and types purchased. While there was a
loss of personal information, no purchasing information was associated
with that, other than merchant id's and transactional reference
numbers/amounts.

The breach occurred after CardSystems inappropriately held onto card
data for "research purposes" rather than deleting it. Forty million
accounts were exposed, and records pertaining to at least 200,000 are
known to have been stolen, primarily MasterCard and Visa cards.

For this, CardSystems should be sued into oblivion. For the life of
me, I can see no reason a clearing house would retain information of
this nature for "research purposes," as clearing houses really should
be nothing more than aggragation/forwarding services for their
clients. As far as I'm aware, the clearing house used by my employer
has not had any publisized security breaches. Given the way my
employer operates, I'm certain that if there were any known security
breaches with our clearing house, we would have found another one. :-)

That's all well and good, but it's still very reactionary: let's wait
until they have a breach, and if then we'll dump them and find another
clearing house. Are there any steps being taken to PREVENT such
incidents for occurring in the first place?

I got the impression from the article that the clearing houses are
still the weakest points in the chain, and I agree with you about the
reactionary stance. Given that, all we can do is to select a partner
with a good track record, and do our best to make sure our side is
buttoned up tight.

I don't know about TJ Maxx's scale, but I do know that it would be
impractical for my employer to track items sold to individual
customers. We have *way* too many customers and transactions to make
it a realistic endeavor

It's a daunting task, but disk space is getting cheaper every day, as
is computing power in general.

True, and from the point of sale to the data mart, we're beefing up
our infrastructure and bringing our systems into much tighter
integration with each other. I get dragged across an interesting and
diverse array of projects, as I usually get assigned the stuff no one
knows how to do. :-/

One local grocery store chain uses a "club" card and tracks how much
we spend on wine and pet supplies. The idea is when we spend a certain
amount in that category we get a coupon for a discount towards our
next purchase in that category. No doubt they simply keep a running
total of the amount spent in each category as opposed to tracking each
and every purchase; similar data reduction techniques are undoubtedly
employed on every purchase we make, and that information is used to
target us with other marketing.

But a club card is not a payment card, or if it is, it's one that
you've opted in for, like a gift card. At the point of purchase or
application for such a card, you're giving the retailer permission to
use this information for tracking purposes. The consumer is not giving
permission to track purchases based on credit card numbers, which is
why PCI compliance is an issue. As PCI came up, the retailers and what
not started implementing gift/club cards to be able to remain
complaint, as well as to continue their data mining operations.

For example, they might have a "baby" category. Every time you buy
diapers, baby wipes, and other baby paraphernalia, they might maintain
a count of the number of items purchased and the total dollar amount
spent. From that, they might estimate how many children you have and
their ages (as a totally contrived example, if you were buying diapers
in 1990, they might be sending you ads for college loans now because
they know you have a kid who is about to graduate from high school).

We track our sales in a similar manner, although again, we don't care
about who, only how many, customers purchased a certain item or from a
certain group. The piece we have in place actually allows those
"monitoring" the data to make some definitions which are automagically
pushed to the sites (and this is controllable based on region or site
if necessary), at which time it drives a data mining process at the
site level for preparation of the information to be sent back for the
data mart back at home.

Other more complicated information tracking request will involve a
member of my team. My first two "evaluatory" projects were in this
line, and when I successfully completed them, I was offered a
position. After being handed my offer, I thought to myself: "They want
to pay me this much to do THIS? Sign me up!" as it was relatively easy
work. Unfortunately I haven't had any such simple projects as
information extraction since I accepted. :-)

OBTW, how do pay-at-the-pump credit card terminals get access to your
ZIP code? Here in SoCal, when you want to pay for gasoline at the pump
using a credit card, they ask you to punch in the billing ZIP code for
your credit card. Presumably if you punch in the wrong ZIP code your
purchase will be denied. Isn't that a violation of the PCI rules?

I believe you have that in the Bay area, as well as some stores in
Florida.

Using the zip code from the track 2 data for verification isn't a
violation if the information is not stored after the transaction is
complete. Using the zip code is a decent idea, (IMO) as it's a step in
the authorization process that can be initiated without opening a
connection to the clearing house.

I know this is way off-topic, but it's also fascinating to me. :)

I've found it to be an interesting, and sometimes frustrating,
learning experience. :-)


--

"Speeders And Drunk Drivers Are MURDERERS" brags of it's homosexuallity:
the guys at the bath-house stopped laughing at my 3 inch weenie.
: http://groups-beta.google.com/group/rec.autos.driving/msg/168e8e621dd649fb?hl=en

"Speeders And Drunk Drivers Are MURDERERS" brags of it's ability to operate a vehicle:
I must be doing something right to go 3 1/2 years without a fatal crash.
: http://groups.google.com/group/misc.transport.road/msg/a376114ee8a61824?hl=en
.