Top Five Causes of Data Compromise

Steve writes, "In a key step to help businesses better understand and protect themselves against the risks of fraud, Visa USA and the U.S. Chamber of Commerce announced the five leading causes of data breaches and offered specific prevention strategies. The report states that the most common cause of data compromise is a merchant's or a service provider's encoding of sensitive information on the card's magnetic stripe in violation of the PCI Data Security Standard. The other four are related to IT security, which can be improved simply by following common-sense guidelines." Here is the report on the U.S. Chamber of Commerce site (PDF).

Comments

top 5

[neonprimetime]

1. Storage of Magnetic Stripe Data
2. Missing or Outdated Security patches
3. Use of Vendor Supplied Default Settings and Passwords
4. SQL Injection
5. Unncessary and Vulnerable Services on Server


Honestly, could my post be any more useful?

Re:top 5

[grammar fascist]

4. SQL Injection

I'm surprised, but not too much. It's interesting that this is the only one on the top five list that has anything to do with the programming. This puts it right up there with social engineering - SQL injection is that easy.

The take-home lesson for us programmers? Never, ever, EVER use any DB API that doesn't let you bind parameters.

Re:top 5

[DavidWide]

php.net/mysqli has prepared statements, or you can use PEAR's MDB2:

* Prepare/execute (bind) named and unnamed placeholder emulation

Re:top 5

[doublebackslash]

PostgreSQL has had an escape function for years. Just pass and null terminated string to the function and it returns a string (or a pointer to a string, depending on the language) and that is safe to put in a SQL query. Honestly it is just that easy.

A bit more about #1

[Ritchie70]

I work for a major merchant in the US. We take just a ton of credit cards, and have ongoing Visa PCI/CISP discussions.

For those who don't know, the magnetic track on a credit card actually has three tracks worth of data. Tracks 1 and 2 both have the account number; track 1 also has your name and perhaps some other stuff. I'm more familiar with track 2.

Track 2 has the card number, the expiration date, and something called "discretionary data." The discretionary data, so far as I can ascertain, is defined by the issuing bank or organization, and has no (publicly documented) inherent meaning - except "we'll cut your balls off if you store this for any period of time."

You can get away with storing the entire track worth of data if you're doing offline approvals, but once you get the approval, you had better ditch the discretionary stuff.

We do some fraud detection in the POS system with a SHA-1 hash of the card data. As you all (should) know, this is a non-reversible hash. We're so paranoid about the discretionary data that we only even calculate the hash of the card number and expiration date - we don't even include the discretionary data in our hash calculations!