Data Loss

Thoughts on Data Breach History

By Rich

I've been writing about data breaches for a long time now -- ever since I received my first notification (from egghead.com) in 2002. For about 4 or 5 years now I've been giving various versions of my "Involuntary Case Studies in Data Breaches" presentation, where we dig into the history of data breaches and spend time detailing some of the more notable ones, from breach to resolution.

2 weeks ago I presented the latest iteration at the Source Boston conference (video here), and it is materially different than the version I gave at the first Source event. I did some wicked cool 3D visualization in the presentation, making it too big to post, so I thought I should at least post some of the conclusions and lessons. (I plan to make a video of the content, but that's going to take a while).

Here are some interesting points that arise when we look over the entire history of data breaches:

• Without compliance, there are no economic incentives to report breaches. When losing personally identifiable information (PII) the breached entity only suffers losses from fines and breach reporting costs. The rest of the system spreads out the cost of the fraud. For loss of intelectual property, there is no incentive to make the breach public.
• Lost business is a myth. Consumers rarely change companies after a breach, even if that's what they claim when responding to surveys.
• I know of no cases where a lost laptop, backup tape, or other media resulted in fraud, even though that's the most commonly reported breach category. Web application hacking and malware are the top categories for breaches that result in fraud.
• SQL injection using xp_cmdshell was the source of the biggest pre-TJX credit card breach (CardSystems Solutions in 2004: 40 million transactions). This is the same technique Albert Gonzales used for Heartland, Hannaford, and a handful of other companies in 2008. We never learn, even when there are plenty of warning signs.
• Our controls are poorly aligned with the threat -- for example, nearly all DLP deployments focus on email, even though that's one of the least common vectors for breaches and other losses.
• The more a company tries to spin and wheedle out of a breach, the worse the PR (and possibly legal) consequences.
• We will never be perfect, but most of our security relies on us never making a mistake. Defense in depth is broken, since every layer is its own little spear to the heart.
• Most breaches are discovered by outsiders -- not the breached company (real breaches, not lost media).

The history is pretty clear -- we have no chance of being perfect, and since we focus too much on walls and not not enough on response, the bad guys get to act with near impunity. We do catch some of them, but only in the biggest breaches and mostly due to greed and mistakes (just like meatspace crime).

If you think this is interesting, I highly recommend you support the Open Security Foundation, which produces the DataLossDB. I found out only a handful of hard-working volunteers maintains our only public record of breaches. Once I get our PayPal account fixed (it's tied to my corporate credit card, which was used in some fraud -- ironic, yes, I know!) we'll be sending some beer money their way.

–Rich

Sprint Customer Data Leaked … again

By Adrian Lane

Brian Krebs posted last week that Sprint is claiming an employee has stolen customer data, including pin numbers and the "security question" you can use to recover a password. This is a vendor I have been following for a long time, and I'm surprised we have not seen this type of activity before. From Brian's blog:

"It appears this employee may have provided customer information to a third party in violation of Sprint policy and state law. We have terminated this employee. The information that may have been compromised includes your name, address, wireless phone number, Sprint account number, the answer to your security question, and the name of the authorized point of contact on your account."

I wonder if they ever managed to remove the customer's social security number as the primary key for their customer care database? It would appear that they did at least remove CC# and SSN# from the customer care application UI, which was my primary beef with them:

"We implemented a billing platform about a year ago that has advanced security features designed to catch things like an employee accessing information that they shouldn't be," Sullivan said. "That platform limits information that employees can access, such as Social Security numbers, and any sort of payment information."

I have always considered Sprint lax in regards to their data security practices. They exposed my information before any breach notification laws were in effect, with my personal and billing information going to a third party. Worse, the person who obtained the data called customer care and was subsequently provided my SSN# and was able to shut off my account. Not sure what these "advanced security features" are exactly, but I would need to concede that the improvement must be working if the credit card numbers that they require for account creation were not stolen as well.

I really do wonder if (hope) this will prompt some form of internal investigation, and I always wonder if Sprint could be considered a contributor in this breach case if they provided employees far more data that was necessary to do their jobs. Think of it this way: If it was "thousands" of accounts, clearly the employee must have had access and been able to copy them electronically.

–Adrian Lane