Credit-Card Data Breaches Drive Security Solutions

4foot10 writes with a link to a CRN article about the booming business of PCI adoption. The Payment Card Industry Data Security Standard (PCI DSS) was worked out by credit card companies as a guideline for securing customer data. As a series of high-profile customer information leaks have occurred over the last year, the business is increasingly getting lucrative for those who can keep up. "As PCI-related business begins to boom, security VARs and integrators find themselves in the enviable position of having almost too much work to handle. And there's plenty of room for the market to grow: Visa estimates that just 36 percent of Level 1 merchants (which process more than 6 million credit-card transactions annually) and 15 percent of Level 2 merchants (which process at least 1 million) have complied with PCI. Solution providers can either handle PCI-related assessments of companies' networks and then recommend solutions to address holes, or provide the remediation services after an audit, which often requires companies to implement firewalls or encryption to their networks."

The standard itself

[ergo98]

The PDF [pcisecuritystandards.org] isn't full of anything revolutionary, and most are just common sense data security, but it is a great starting point for securing virtually any highly confidential data.

Far too many shops don't comply with the majority (or any) of the recommendations.

Re:

[4e617474]

and most are just common sense data security

Oh, if only. Until recently I worked for a company that sells systems that perform credit card transactions for a particular segment of merchants (I don't want to say more than that for reasons that will become obvious soon enough. They went through a series of revisions in their product lines, but for the most part the systems are very hard to set up, configure, and troubleshoot, and if you were going to go looking for the most technically inept customer base t

Re:

[failedlogic]

Wow. Well at least I take pride in only using cash (no debit cards) for fear of these situations. I'm fearful this is a lot more common.

Re:

[Mondor]

If you would only know how right you are. There are two major problems with PCI standard. First, it is greatly outdated. It tries to push some "well known and proven" security measures as if there could be no others more effective. It is like instruction to put red flags around the lawn to keep wolves away. You may get a high-tech fence instead, and this would solve the problem, but this would not make you compliant. Just put these red flags on.

And second, which is funny, you don't have to pass PCI audit to

Putting a band-aid on a sucking chest wound

[Dachannien]

Instead of coming up with all these technological countermeasures, why don't the credit card agencies simply stop offering credit without actually verifying the identity of the credit requestor? Make the data useless by itself, and people will stop trying to obtain it.

Oh, that's right, it's more lucrative to give out credit like candy, and then put responsibility for fraudulent charges on the merchants.

Re:

[jd3nn1s]

The PCI DSS has nothing to do with stopping fraudulent credit applications. It's about making sure that payment information you have given to a merchant is protected from security breaches. The merchant is rightly responsible for this.

Re:

[Dachannien]

You don't get my point. If the payment information is worthless to identity thieves because they can't do anything with it, then there'll be no need for putting the burden for ridiculously heightened security on merchants.

Re:

[scdeimos]

The "ridiculously heightened security" as you put it is just common sense. It was only a couple of years ago that you could routinely use search engines like Google to search retailer web sites for files (as basic as plain text files and Access databases, etc.) containing customer payment and shipping information. Nowadays most retailers at least have their payment databases out of the webroot space (often on a different server), but I doubt whether more than a very few of them actually store the card data

Re:

[jd3nn1s]

How do you make the payment information worthless to someone wishing to carry out fraudulent purchases without new hardware systems?

layers 1-3 aren't the biggest problem

[bl8n8r]

The biggest problems facing internet security are greed, laziness, ineptitude, apathy and general ignorance. expensive credit card hardware cant fix pebkac, all it does is make newegg raise their shipping charges.

Re:

[Master of Transhuman]

I agree with that entirely, but it also extends to the people writing the software and the devices.

I have a client (more than one, actually) running QuickBooks 2007. This POS has to run as Administrator on a Windows box. There is theoretically a way to change that but the Web page describing it is extremely long - and there are no guarantees that the next update (QuickBooks has released many recently because the 2007 version is buggy as hell) won't screw that up.

So in essence the entire small business marke

when even the source doesn't have a clue

[l3v1]

I mean come on, the linked writing has the following text

Security experts say every time a retailer ends up in the headlines for losing customer credit-card data, a PCI project gets its wings. And,as more companies look to the channel for help with securing their networks for PCI compliance, it's turning out to be a wonderful life for solution providers.

in which they link the PCI acronym to an encyclopedia site detailing what PCI as in Peripheral Component Interconnect means.

Good job.

PCI is Paternalism

[Alexander]

The standard, while a nice list of controls, has only a slight chance of helping those cannot/will not manage their risk. In the mean time it is nothing but another layer of wasteful bureaucracy (redundant?) for those who do a good job of managing their risk.

But we call all rest easy knowing that some vendor has spent $5 per IP to get a "hackersafe" badge to throw up on his webiste.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[NC-17]

With specific Recurring Billing flags sent to the appropriate processor, perhaps with a reference to the original transaction as well. It can be done.

No it doesn't

[Chuck Chunder]

It just means processing through a terminal where CVV is not a requirement.

I have worked with several gateways/processors and the details depend a lot on their implementation. However typically we set up two accounts, a CVV account and a non CVV account. We funnel initial transactions through the CVV account and recurring transactions through the non-CVV accounts.

Sometimes explicit linkage is required (ie a transaction reference for the initial transaction) and sometimes there is just "trust" that the no-CV

Re:

[DogDude]

The CVV isn't required for many merchant banks. Many merchant banks require other forms of extra information instead of the CVV, like the billing zip code.

Re:

[AJWM]

Heck, I've seen self-service gas pumps that require the billing zip code.

Mind, with the price of gas, I can understand the desire for extra security.

Re:

[Planesdragon]

This is easy.

1: Authorize a single transaction, including date/time, CC#, expiration, and ammount.

2: Authorize "recurring payments", which stores #1 and includes what limits (if any) on the recurrence. (15/month? "paid in full" a month?)

3: For each recurring payment, including CC# (et al) and reference to #1. Processor checks #1, and if it is (1) still valid and unrefuted and (2) satisfies #2's limits processes the payments.

Re:

[NC-17]

I would say, because it seems like such a large part of your business, that you find a new gateway/processing company to deal with, that already has this functionality in place. They do exist :)

Bullshit

[bluefoxlucid]

Like any document, it gives a smart person a starting point and a dumb person (company) a way to say they're secure when they're really not. You need a 'firewall' and an 'IDS'; devices that qualify for this can do bare ass nothing (if you can justify why it's open and why you use it, it's probably fine to have open), though you can get a good tight firewall NEED-TO-ACCESS policy (allow what you need, isolate the servers from each other, deny any). I believe you can have access to the SQL database from the

Re:

[jd3nn1s]

The most recent version of PCI DSS states that any direct external availability of DBMS is an instant failure, and this is tested by the ASVs (or at least it should be). Any buffer overflows in remote available services should also be detected by the required quarterly vulnerability scans.

Re:

[Alexander]

"These documents are excellent for true security engineers"

No. They're not. And for *true* risk managers, they're a joke and a waste of time.

encrypt transmission across public networks ..

[rs232]

You don't send sensitive information across the Internet period. On the client run an application that generates a unique one way hash of the transaction. This is sent to the server which performs the same hash using data stored on the server. It then sends a confirm msg to the client.

On the server the data is stored encrypted and is accessed through well defined system calls. The encryption is done by a hardware module that sits between the harddrive and the system. That way if the server is sucessfully ha

Re:

[jd3nn1s]

So how does the server learn the credit card number etc necessary to perform the transaction?

Re:

[rs232]

'So how does the server learn the credit card number etc necessary to perform the transaction?'

When you apply for a card, the server generates a unique identity. These details are stored on the card and on the server. The card is sent out to you and when in use a processor on the card generates a one time encrypted transaction from the data on the card. This is sent across the network to the server. The server performs the same transaction on the data stored in the server. If the two matches then the tr

Re:

[jd3nn1s]

OK so this solution requires additional hardware to allow your computer to interface with the chip on the card.

What is the point for a lot of this when the out..

[Joe The Dragon]

outsourced call center has all of your info and passwords.

It's just broken

[Jessta]

The current way in which credit cards number are used is just broken. I find it amazing that it hasn't been fixed yet.
Requiring that to make a purchase you have to give a shop all the information they require to make additional purchases on your behalf is just stupid.
The solution is simple, public/private key cryptography.
eg. http://jesstaa.blogspot.com/2006/06/credit-cards. h tml [blogspot.com]

Have to stop storing them

[sam_handelman]

It simply ought to be illegal for a business to store your credit card number (or bank account number.) In fact, it ought to be possible - especially on the internet - to do business without even disclosing your credit card number. The business opens a connection to Visa, and gives your browser the info it needs to complete the transaction from your end.

If people want to bill you every month - they should send *you* an account number (which they could make easy to do, as above) and you instruct you

Credit-Card Data Breaches Drive Ambiguous Titles

[wirelessbuzzers]

Wow. I always thought that the benefits of those encrypted Seagate drives were marginal, but I'd never have guessed that you could breach them with just a few credit card numbers.

Scanning only part of PCI

[Chuck Chunder]

My perspective on PCI compliance, from working with our customers on it, is that it is actually a crapload of work for companies to do. The standard is actually a pretty high bar. For example, a webserver that allows SSLv2 will fail you, or a VPN device that allows connections with regular DES.

Making sure the systems don't raise any security scanning flags can be a pain but mostly it's a tick the box affair. (I have had to handle the SSL issue you mention. Actually disabling SSLv2 is easy, the hard part is