Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Top Five Causes of Data Compromise

Posted by kdawson on Mon Sep 18, 2006 04:18 PM
from the it's-the-data-stripe-stupid dept.
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).
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Volante3192 (953645) on Monday September 18 2006, @04:23PM (#16133772)
    Users! Users! Users!

    Wait, five reasons? Add a 'Users! Users!' to the end of that.
  • Wow (Score:2, Insightful)

    by 1310nm (687270)
    "Use of Vendor Supplied Default Settings and Passwords - In many cases, merchants receive POS hardware or software from outside vendors who install them using default settings and passwords that are often widely known to hackers and easy to guess." Incredible.
    • Re: (Score:3, Insightful)

      by Detritus (11846)
      It doesn't surprise me. The vendor sold them a packaged system. They probably kept all of the manufacturer-supplied documentation for the system's components and provided the customer with a user manual that was written for idiots. Part of locking-in the customer for after-sale parts and services is to keep them ignorant.
    • by SpectralDesign (921309) on Monday September 18 2006, @05:46PM (#16134345)
      POS meant point-of-sale... guess I was mistaken.
    • Re:Wow (Score:4, Interesting)

      by jonadab (583620) <jonadab@@@bright...net> on Monday September 18 2006, @06:07PM (#16134446) Homepage Journal
      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.
    • by dbIII (701233)
      I worked on a short term contract for a company that made POS systems based on win2k. The Admin password for each machine was the name of the manufacturing company and the password could not be changed or remote updating of the software would not work. At least the things were not on the internet so you would have had to know the phone number of the retailer to get in by modem - but I still see it as an incredibly stupid decision - any of the clients could have hacked into the POS machines of their commer
  • top 5 (Score:5, Informative)

    by neonprimetime (528653) on Monday September 18 2006, @04:24PM (#16133784)
    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: (Score:3, Insightful)

      by Anonymous Coward
      Honestly, could my post be any more useful?
      Yes, but a more interesting question is could your karma whoring be any more obvious?
    • Re:top 5 (Score:5, Informative)

      by grammar fascist (239789) <neil.toronto@gmai[ ]om ['l.c' in gap]> on Monday September 18 2006, @04:41PM (#16133897) Homepage
      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: (Score:3, Interesting)

        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.
      • That's one of the reasons I love PHP's newer PDO library. It uses the native data binding for the DBMSes that support it, but will emulate it for those that don't. Thus, no need to worry about manually quoting/escaping the input.
      • by jesser (77961)
        It's interesting that this is the only one on the top five list that has anything to do with the programming.

        I disagree. #2 and #5 also refer to software vulnerabilities (indirectly). If software didn't have vulnerabilities, #2 and #5 wouldn't be issues.
        • Re: (Score:3, Informative)

          by DavidWide (978087)
          php.net/mysqli [php.net] has prepared statements, or you can use PEAR's MDB2 [php.net]:
          * Prepare/execute (bind) named and unnamed placeholder emulation
        • Re: (Score:3, Informative)

          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.
    • No social engineering? Which is a superset of phishing? It's still a data breach even if it doesn't happen on the merchant side.

      BTW the PCI/DSS is much more practical than, say, HIPAA. They talk in straight lines instead of circles and give you directly actionable advice.
  • by creimer (824291) on Monday September 18 2006, @04:30PM (#16133829) Homepage
    Whatever happened to the old saying that your credit card would more likely be ripped off by a waiter than someone off of the internet? Or are waiters taking hacking jobs these days?
    • by jamesh (87723)
      Statistically i think it's still more likely to happen in a restaurant, although i haven't seen any recent research which would support this.

      The thing about doing it on the internet is that it's much easier to 'steal' thousands of numbers with minimal effort (compared to the effort required to do it a non-internet way).
    • Whatever happened to the old saying that your credit card would more likely be ripped off by a waiter than someone off of the internet? Or are waiters taking hacking jobs these days?

      That would be part of number 1, putting all the information on the magnetic stripe. Waiters might know how to do this too.

      Then again, this is a paper about data security not fraud in general. If you want advice about that, visit the FTC site [ftc.gov] where crooked clerks are front and center.

    • Re: (Score:2, Interesting)

      by jonadab (583620)
      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.
    • Re: (Score:3, Insightful)

      by MrNougat (927651)
      Credit cards are most likely to be ripped off where they are used most often. People use credit cards online a lot now, more than they did when that saying was originally said. Also, because the unwashed masses have this idea that The Internets are made of magic fairy dust distilled directly from truth and love, they're prepared to believe whatever The Internets tells them.

      Thieves steal what's easiest to steal and get away with.
    • by mennucc1 (568756) <d3@tonelli.sns.it> on Tuesday September 19 2006, @03:55AM (#16136422) Homepage Journal
      You did not RTFA: waiters are number one in the list. Here it is, in the original form:
      1. Storage of Magnetic Stripe Data - The most common cause of data breaches occurs when a merchant or service provider stores sensitive information encoded on the card's magnetic stripe in violation of the PCI Data Security Standard. This can occur because a number of point-of-sale systems improperly store this data, and the merchant may not be aware of it.
      Then translate from market-speak:
      • service provider -> waiter (indeed, it does serve)
      • merchant -> owner of the restaurant
      • "point-of-sale systems" -> gadget that you stripe your card in
      • to store sensitive info -> pwn
      After proper translation, it reads:
      1. Storage of Magnetic Stripe Data - The most common cause of data breaches occurs when a waiter pwns your card's magnetic stripe in violation of law. This can occur because a number of gadgets are available around that will store this data; and the restaurant owner may not be aware of it.
      See?
  • Chip & PIN (Score:5, Interesting)

    by celardore (844933) <celardore@gmail.com> on Monday September 18 2006, @04:58PM (#16134015) Homepage
    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.
    • Re:Chip & PIN (Score:3, Insightful)

      by smoker2 (750216)
      Yeah, or they could stand behind you at the ATM and then lift your wallet, or, maybe just beat you over the head right there and get some quick cash. How is a 2 stage authentication worse than a single stage ?

      In Oz and New Zealand, people buy beer in the pub and pay like that (EFTPOS IIRC) and I don't think they are having a huge problem. They started a good while before us too.

      Also, having your PIN doesn't give them your account. They would be limited to whatever your bank has set for the cash limit for th

      • I forgot to mention : If they had thought to require a photo for the front of the card then it would be a 3 stage process, and pretty hard to circumvent in a store situation. Even ATMs have CCTV these days, so they could use some image recognition software to match your image against the registered image before giving you cash. Personally I prefer cash....
        • Re:Chip & PIN (Score:4, Insightful)

          by John Hasler (414242) on Monday September 18 2006, @09:38PM (#16135406)
          > If they had thought to require a photo for the front of the card then it
          > would be a 3 stage process, and pretty hard to circumvent in a store
          > situation.

          Clerks rarely check pictures[1].

          > Even ATMs have CCTV these days, so they could use some image recognition
          > software to match your image against the registered image before giving you
          > cash.

          And the software would screw up about 10% of the time, keeping your card and your money.

          [1] I knew a guy who spent part of his stint in the Navy sneaking on board warships with an ID card bearing the likeness of a gorilla.
    • Signatures were not normally verified/questioned at checkout plus the signature is on the back so pin numbers are more secure.

      Anyway, the move to chip and pin has certainly caused a drop in the cost of fraud to VISA/Mastercard - during the switch they moved the liability for fraud onto retailers!
      This was clearly the main reason for the move to chip and pin - it had nothing to do with protecting consumers, they weren't liable for fraud under the old system anyway.
    • I think one of the greatest mistakes the credit/debit card companies/banks made was the compulsary PIN entering at point-of-sale.

      So cover the keypad when typing in the PIN. Duh! Even the only-slightly paranoid should do that.

      But this brings up another point: how hard is it to clone one of those chip-and-PIN cards anyway? I'd hope that it would be at least somewhat difficult, ideally with an on-chip crypto engine that doesn't let its private key go "off chip". Such a system would be really hard to use in an

        • Huh? Twofish/AES can handle 256 bit encryption in ~400K transistors with a speed of 104Mb/s, doing strong encryption doesn't have to take a lot of power or chip realestate.
    • Re:Chip & PIN (Score:2, Insightful)

      by Monkier (607445)
      "skimming" has already happened in the UK, USA and Australia.. where an additional magstripe reader is attached to an ATM, or POS card reader - and some other means is used to capture your PIN (hidden camera or alike). the magstripe data can be used to easily clone a magstripe only card.

      the chip & pin approach in the UK introduces a smartcard chip into the mix. the chip makes the card difficult to clone. the chip is a mini computer that will only give up the account identifier when given the PIN sign
      • Re:Chip & PIN (Score:3, Insightful)

        by oPless (63249)
        > the chip & pin approach in the UK introduces a smartcard chip into the mix. the chip makes the card difficult to clone.

        Sorry, that's bollocks - there has already been a student that has been able to 'crack' the encryption (I can't cite any references, and it was a month or two ago) But I did find this http://www.hebdos.net/lsc/edition352006/articles.a sp?article_id=140973 [hebdos.net]

        Despite this, that there is a simple bit flag on the mag stripe that determines "this card is chip and pin" which can be turned o
    • 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.

      As opposed to before, when all they had to do was lift your wallet and spend a couple of minutes practicing the signature helpfully provided on the reverse? (Not that anyone ever checked them in my experience anyway - I actually managed to buy something on my gf's card once when I grabbed the wrong one on my way out of the house, a
    • Re:Chip & PIN (Score:3, Interesting)

      by eunos94 (254614)
      There are other factors at play here too (at least in the US). Stores want you to use your PIN as opposed to signing because it turns it into a different type of transaction. PIN is a debit account, which costs the store close to nothing. Signing is a credit transaction, which costs the store something. Banks want you to sign, they will get some sort of interchange income back from VISA. If you PIN, they don't make anything. Additionally, if you are using a VISA-like product, often using your PIN will
  • Reasons? How about: (Score:2, Interesting)

    by TheWoozle (984500)
    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 se
    • Umm... "cash".

      'Nuff said.
      • I've read about some vulnerabilities involving theft of security tokens and untraceable access to your assets with this "cash" protocol.
    • Asymmetric crypto already provides the foundation for what you've described.

      With the appropriate public key infrastructure, the necessary amount of information associated with a key pair can be made public, while the rest remains private so that it can be applied in cryptographically secure ways, for example to certify a transaction, without exposing the information itself.

      Not many people understand how this works, so it's been historically hard to deploy, but it can be done.

      • ...that it requires a company with as much clout as Microsoft to stand up and say: "hey we should be doing this, here's the API, now get coding to it" in order to make anything useful happen anymore.
  • by Plutonite (999141) on Monday September 18 2006, @05:39PM (#16134310)
    Or something :) [slashdot.org]
  • PDF (Score:3, Funny)

    by Gnavpot (708731) on Monday September 18 2006, @07:10PM (#16134779)
    I miss one item in that list:
    "PDF documents with readable text under the black rectangles."
  • A bit more about #1 (Score:2, Informative)

    by Ritchie70 (860516)
    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
  • I work for a company that provides the back end for loyalty processing systems. One day in 1999, the front end company complained to us that our system was rejecting their new cards, saying they had an invalid expiry date.

    Now, ISO specification for track-2 on a magnetic stripe card is: the card number, then a delimiter, then an expiry date in YYMM format, and then freeform data to a maximum of 37 characters. There are tens of thousands of installed systems that read these cards and parse the expiry date.

    But
    • by Nintendork (411169) on Monday September 18 2006, @09:36PM (#16135396) Homepage
      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 [visa.com] 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.
    • Sure they are pretty obvious, but it's the ordering that is surprising.

      1. Storage of Magnetic Stripe Data
      Once you know it, it's obvious. I bet you wouldn't guess it before. My bet was social engineering. What a surprise, it's not even on the list.

      2. Missing or Outdated Security patches
      This one is pretty obvious, although I bet 50% of you would bet on 0-day exploits instead.

      3. Use of Vendor Supplied Default Settings and Passwords
      I personally thought this one died around the end of the last century, and the v