Slashdot Mirror
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).
I only have knowledge on Javas's JDBC API, which allows it both ways. The interesting thing is that it's generally easier to use bind parameters than to build sql by hand, but I still see some people that do it. Not that many people code to JDBC these days, it's considered very low level in Javaland. We like levels and levels of frameworks above our JVM, which is already levels and levels above the SO, which is... you get the picture.
Perhaps slightly OT, but the article is slashdotted and the header mentioned VISA and breaches.
I think one of the greatest mistakes the credit/debit card companies/banks (certainly here in the UK) made was the compulsary PIN entering (as opposed to a signature) at point-of-sale. Now all you need to do is stand behind me and see my PIN, or if you work at the store - have the security camera trained at the keypad then either lift my wallet or clone my card. All you need is that four digit number, and you've pretty much got my bank account.
My point is, companies make fundamental security errors, and will continue to do so.
1. Having your sensitive information recorded in any medium.
That's it.
Really, there's no such thing as perfect security. If you have any information that you want to keep secure and you tell it to even one other person, it will eventually be accessible to anyone who has enough interest in it.
Hell, if we don't rule out torture, you yourself aren't a reliable repository for your own sensitive information.
But you have to share certain information with others if you want to do business, don't you? Well, it seems to me that the only way to avoid all the mess and hassle is to either:
1. Develop a system of doing business where I don't have to be able to identify a person and keep track of that person and/or their assets (goodbye credit-based economy!)
OR
2. Make it so that even if the information used to idenitfy me is made public, it doesn't matter in the slightest.
The second choice means that the information a business uses to establish my identity has to be enough to authenticate me in some manner to that business, but is otherwise useless to identify my person (age, gender, race, etc.), my place of residence, my bank account, my credit rating, or anything else about me.
Hmm... I think it's possible, but not likely. The banks and corporations very much enjoy knowing all this about you, and it will be a mighty struggle indeed to wrest control of your "personal information" away from them.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
Some vendors who develop industry-specific software actively encourage this.
When I mentioned to a trainer who works for our vendor that I would of course be changing all the passwords away from the (incredibly insecure) defaults, the response I got was, "Why? What are you afraid of?" Later, _a technician_ working for the vendor asked, "You didn't change the Administrator password, did you?" I wanted to say, "Of course, what kind of fool do you take me for," but all I said was, "Yes, I did." They didn't make me change it back, but they also didn't seem to understand why I considered it important to change it.
Worse, when I asked what ports I needed to open on the firewall between the staff workstations and the mission-critical production server, I was told that we _cannot_ put a firewall there; they must be directly on the same subnet.
This was all _after_ we bought the software, to the tune of tens of thousands of dollars. Before we bought it, the official line was that the only thing that could possibly make the system vulnerable would be if we neglected to keep up-to-date antivirus software. My boss (at the time, now retired) actually signed (against my advice) a contract agreeing that if there's any security incident, it's automatically our fault and _we_ pay the _vendor_ for any time required to fix it.
Needless to say I am personally rather at odds with this vendor's view of security. Their name is Polaris Library Systems.
Cut that out, or I will ship you to Norilsk in a box.
For you as a consumer, that's probably still true, but the article's target audience is concerned about preventing the kind of situation that gets your organisation a lot of negative publicity because a large number of your customers' data have been stolen.
Cut that out, or I will ship you to Norilsk in a box.
I'm in the IT department for a large ISO and give the security lecture during new hire orientations. We have to follow PCI compliancy and are aware of the dangers on the Internet. Insider jobs are a threat, but not yet. Right now, most of the crime is organized out of European countries and the most they use outsiders for is as a mule. The list they gave along with social engineering is actually quite acurate. CardSystems, an ISO with some 119k merchants was compromised last year due to a SQL injection attack and the storing of track 2 data of failed transactions on their processing hosts in plain text. Part of PCI compliancy is to only store that data in a strongly encrypted form (They give examples) and it's common practice to only store it during standin (When the upstream processor is down) and after standin until all the transactions run through successfully. They really f*ed up! The debit card fraud that happened earlier this year is still under investigation, but rumors have it that the POS system that Sams Club and/or OfficeMax use to send all the transactions to their processor was compromised. Of course, we won't know the story until the feds either give up or find the criminals.