2009 DBIR: Compromised Data

Bryan Sartin
April 14th, 2009

To my mind, this section included several areas of interest. The sheer number of compromised records we investigated in 2008 is surprising – even to us. Only time will tell how the numbers will stack up in 2009 but we’ve already worked several large cases this year.

One of the things we discussed internally when analyzing the data from 2008 was how useful the “% of records” statistics would be since it was so dominated by a few large breaches (the largest 4 or 5 breaches exceed 90% of all 285 million records). We thought about removing them. We thought about pulling them out and presenting them separately alongside the smaller yet more numerous breaches. In the end, we decided keep everything together and provide distributions, measures of central tendency, etc to describe the data set.

The breakdown of data types shown in Figure 29 of the report was not unexpected and probably not surprising to many. However, I have fielded a huge amount of questions and interest with respect to the discussion around PIN data. In retrospect, it would have been wise to call this out separately and we will do so in the next report. Attacks targeting this type of data were, without a doubt, one the defining developments in the world of cybercrime in 2008. Unfortunately, I feel we will be dealing with it for some time to come.

Tags: , , , , , ,

Comments

  1. ACI Worldwide is the largest supplier of payment card processing software in the world – half the plastic transactions in the world go through our software at various customers sites. We are experts on PIN security and participate actively in the ASC X9F6 working group on mag stripe and ICC security.

    Yhe comments in the DBIR about PIN cracking are tantalizing but incomplete. We and many other vendors in the PIN security space would keenly like to understand more about the specifics. Our customers are asking us about the risk.

    The press has been conflating several issues into the this same story:

    - PINs in the clear: PINs are never in the clear when HSMs are used. In fact, the use of s/w cryptography for PIN security is forbidden by all the card brands.

    - PIN cracking at the HSM: Using the unbearable lightness of PIN cracking technique requires that PIN format translation commands are enabled and that the attacker has access to the HSM, which is usually LAN attached. Of the thousands and thousands of switching and authorization systems, few could be counted on to have both these conditions met. We find it hard to believe that these compromises where caused by external malware, without the assistance of an internal accomplice.

    - The payment card system is broken and needs to be replaced: We have a replacement – it is called Chip & PIN, using EMV smartchips on cards in place of mag stripes. In the U.K. where it has been most widely deployed, it has driven fraud to card not present with online merchants. Cracking the PIN for an EMV card is a totally different cryptography problem. However, the cost to implement Chip & PIN in the U.S. has been estimated to be $15B. Who will pay for it? Should the issuers add a surcharge on to their cardholders bills? Up interchange fees? Should merchants just bear all the cost? Pay for it our of Obama’s stimulus package?

    In summary, the DBIR has made my life harder, without any actionable data to use to help our customers harden there systems. It smacks of “security researcher FUD” and a press grab.

    Posted by: Sid Sidner on April 29th, 2009 at 8:25 pm
  2. @Sid

    Sorry it’s made your life harder, Sid – I assure you it wasn’t our intention. It certainly wasn’t our intention to spread FUD and I must admit the accusation gets under my skin a bit. We try hard NOT to do that in everything we do and I think/hope few people out there view the report in that way.

    Most feedback we’ve received leads us to believe that the DBIR makes life easier for the majority of people out there. It’s real data. It helps shape a security program around preventing things that really happen. The data might not be as specific as you’d like it but how could it possibly be and still retain it’s comprehensive nature and digestible length? The DBIR isn’t written for specialized job roles. It’s written to help security professionals and decision-makers better understand how breaches occur and what they can do to prevent and detect them.

    Think about it – a web application security person would want more about the applications we saw exploited and the exact nature of attacks, etc (we actually did have a request for more detail on SQL injection attacks and answered it in the main DBIR post). A malware expert would surely like to see actual code snippets of customized malware and know exactly how criminals remotely plant it on systems. We simply can’t provide all these details in the main report.

    To address this we publish supplemental reports, follow-up blog posts, presentations, etc. In fact, we’ve prepared a private presentation on the exact topic you bring up (more details on PIN cracking) to a group of our customers and other financial services organizations. If you’re legit, I’m pretty sure the folks putting it on wouldn’t have a problem with you joining.

    Finally, I’d like to say that we made a very explicit decision to not include additional details on PIN cracking. We actually had a section written that explained how it was done, the most common methods, what criminals did with encrypted PIN blocks once they had them, etc but we felt that would be more helpful to the criminals than the good guys. In other words, we thought providing the details would make your life harder. We apologize if we were wrong about that but we’re sticking with our decision. We are providing those detailed findings to the financial industry first and the world second.

    Posted by: Wade Baker on May 2nd, 2009 at 1:58 pm

Leave a Comment