Top Five Causes of Data Compromise 106
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).
top 5 (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:3, Informative)
Re:top 5 (Score:3, Informative)
A bit more about #1 (Score:2, Informative)
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!