Data Breach

Creating a Standard for Data Breach Costs

By Rich

One thing that's really tweaked me over the years when evaluating data breaches is the complete lack of consistency in costs reporting. On one side we have reports and surveys coming up with "per record" costs, often without any transparency as to where the numbers came from. On the other side are those that try and look at lost share value, or directly reported losses from public companies in their financial statements, but I think we all know how inconsistent those numbers are as well.

Also, from what I can tell, in most of the "per record" surveys, the biggest chunk (by far) are fuzzy soft costs like "reputation damage". Not that there aren't any losses due to reputation damage, but I've never seen any sort of justified model that accurately measures those costs over time. Take TJX for example -- they grew sales after their breach.

So here's a modest proposal for how we could break out breach costs in a more consistent manner:

Per Incident (Hard Costs):

1. Incident investigation
2. Incident remediation/recovery
3. PR/media relations costs
4. Optional: Legal fees
5. Optional: Compliance violation penalties
6. Optional: Legal settlements

Per Record (Hard Costs):

1. Notification costs (list creation, printing, postal fees).
2. Optional: Customer response costs (help desk per-call costs).
3. Optional: Customer protection costs (fraud alerts, credit monitoring).

Per Incident

(Soft Costs... e.g., not always directly attributable to the incident): Trending is key here -- especially trends that predate the incident.

1. Customer Churn (% increase over trailing 6 month rate): 1 week, 1 month, 6 months, 12 months, n months.
2. Stock Hit (not sure of best metric here, maybe earnings per share): 1 week, 1 month, 6 months, 12 months, n months.
3. Revenue Impact (compared to trailing 12 months): 1 week, 1 month, 6 months, 12 months, n months.

I tried to break them out into hard and soft costs (hard being directly tied to the incident, soft being polluted by other factors). Also, I recognize that not every organization can measure every category for every incident.

Not that I expect everyone to magically adopt this for standard reporting, but until we transition to a mechanism like this we don't have any chance of really understanding breach costs.

–Rich

Open Invitation to the University of California at Berkeley IT Dept.

By Adrian Lane

You probably heard the news last week that hackers have infiltrated restricted computer databases at Cal Berkeley. 160,000 current and former students and alumni personal information "may" have been stolen. The University says social security numbers, health insurance information and non-treatment medical records dating back to 1999 were stolen. Within that data set was 97,000 Social Security Numbers, from both Berkeley and Mills College students who were eligible for medical treatment. I am going to make an educated guess that this was a database either for or located at Cowell Hospital, but there are [very few other details available. Not unusual in data breach cases, but annoyingly understandable and the reason I do not post comments on most data breaches.

This one is different. This is an offer to help UC Berkeley with their data security challenge. As a security professional and Berkeley alumnus, I want to offer my services to assist with security and product strategy to ensure this does not happen again. Free of charge. I am willing to help. This is a service Securosis provides: free strategic consultation services to end users. Within reason, of course, but we do. So I am extending an open offer of assistance to the University.

In 2008, when I was still with my previous employer, we had a couple meetings with IT staff members at UC Berkeley for some of the security challenges and to see if our products were of interest to them. As most initial conversations go, we covered as much background about the environment and goals as we could. While the people we were speaking with were smart and highly educated, the questions they asked and the order of their priorities suggested that they were naive about security. I do not want to provide too many details on this out of respect for confidentiality, but the types of products they were reviewing I would have assumed were already in place, and policies and procedures would have been more evolved. I can even hear Adam Dodge in the back of my head saying "Well ... education is a lot different than the private sector". He's right, and I get that, but for an organization that has already had a data breach through a lost laptop in March 2005, I expected that they would have gotten ahead of the curve. The liability here goes all the way up to the UC Regents, and this is a problem that needs to be addressed.

My goal is not to insult the IT staff at UC Berkeley. Just look at the Privacy Rights web site, or the Open Security Foundation, and you will see that they are no better and no worse than any other university in the country. What pisses me off is that my alma mater, one of the best computer schools in the world, is below average in their data security! Come on!!! This is Berkeley we are talking about. UCLA, OK, I could understand that. But Berkeley? They should be leading the nation in IT security, not the new poster child for University data breaches.

Berkeley has among its student body some of the smartest people in computer science, who gather there from all over the world to learn. When I was there if you wanted to know about inner details of the UNIX kernel, say at 2:30 in the morning, there was someone in the lab who could answer your question. Want to know the smallest of details on network architecture? The 'finger' daemon could point you to the guys who had all the answers. You might need to pull them away from Larn for a couple minutes, but they knew scary levels of detail on every piece of software and hardware on the campus. It is no different today, and they are clearly not leveraging the talent they have effectively.

So go ahead. Ask for help. The university needs assistance in strategy and product suitability analysis, Securosis can help, and we will do it for free.

Now I am going to have the Cal fight song in my head for the rest of the day.

–Adrian Lane

The Data Breach Triangle

By Rich

I'd like to say I first became familiar with fire science back when I was in the Boulder County Fire Academy, but it really all started back in the Boy Scouts. One of the first things you learn when you're tasked with starting, or stopping, fires is something known as the fire triangle. Fire is a pretty fascinating process when you dig into it. It demonstrates many of the characteristics of life (consumption, reproduction, waste production, movement), but is just a nifty chemical reaction that's all sorts of fun when you're a kid with white gas and a lighter (sorry Mom). The fire triangle is a simple model used to describe the elements required for fire to exist: heat, fuel, and oxygen. Take away any of the three, and fire can't exist. (In recent years the triangle was updated to a tetrahedron, but since that would ruin my point, I'm ignoring it). In wildland fires we create backburns to remove fuel, in structure fires we use water to remove heat, and with fuel fires we use chemical agents to remove oxygen.

With all the recent breaches, I came up with the idea of a Data Breach Triangle to help prioritize security controls. The idea is that, just like fire, a breach needs three elements. Remove any of them and the breach is prevented. It consists of:

• Data: The equivalent of fuel -- information to steal or misuse.
• Exploit: The combination of a vulnerability and/or an exploit path to allow an attacker unapproved access to the data.
• Egress: A path for the data to leave the organization. It could be digital, such as a network egress, or physical, such as portable storage or a stolen hard drive.

Our security controls should map to the triangle, and technically only one side needs to be broken to prevent a breach. For example, encryption or data masking removes the data (depending a lot on the encryption implementation). Patch management and proactive controls prevent exploits. Egress filtering or portable device control prevents egress. This assumes, of course, that these controls actually work -- which we all know isn't always the case.

When evaluating data security I like to look for the triangle -- will the controls in question really prevent the breach? That's why, for example, I'm a huge fan of DLP content discovery for data cleansing -- you get to ignore a whole big chunk of expensive security controls if there's no data to steal. For high-value networks, egress filtering is a key control if you can't remove the data or absolutely prevent exploits (exploits being the toughest part of the triangle to manage).

The nice bit is that exploit management is usually our main focus, but breaking the other two sides is often cheaper and easier.

–Rich

Heartland Payment Systems Attempts To Hide Largest Data Breach In History Behind Inauguration

By Rich

Brian Krebs of the Washington Post dropped me a line this morning on a new article he posted. Heartland Payment Systems, a credit card processor, announced today, January 20th, that up to 100 million credit cards may have been disclosed in what is likely the largest data breach in history. From Brian's article:

Baldwin said 40 percent of transactions the company processes are from small to mid-sized restaurants across the country. He declined to name any well-known establishments or retail clients that may have been affected by the breach. Heartland called U.S. Secret Service and hired two breach forensics teams to investigate. But Baldwin said it wasn't until last week that investigators uncovered the source of the breach: A piece of malicious software planted on the company's payment processing network that recorded payment card data as it was being sent for processing to Heartland by thousands of the company's retail clients. "The transactional data crossing our platform, in terms of magnitude... is about 100 million transactions a month," Baldwin said. "At this point, though, we don't know the magnitude of what was grabbed."

I want you to roll that number around on your tongue a little bit. 100 Million transactions per month. I suppose I'd try to hide behind one of the most historic events in the last 50 years if I were in their shoes.

"Due to legal reviews, discussions with some of the players involved, we couldn't get it together and signed off on until today," Baldwin said. "We considered holding back another day, but felt in the interests of transparency we wanted to get this information out to cardholders as soon as possible, recognizing of course that this is not an ideal day from the perspective of visibility."

In a short IM conversation Brian mentioned he called the Secret Service today for a comment, and was informed they were a little busy.

We'll talk more once we know more details, but this is becoming a more common vector for attack, and by our estimates is the most common vector of massive breaches. TJX, Hannaford, and Cardsystems, three of the largest previous breaches, all involved installing malicious software on internal networks to sniff cardholder data and export it.

This was also another case that was discovered by initially detecting fraud in the system that was traced back to the origin, rather than through their own internal security controls.

–Rich

The Breach Reporting Dillema

By Rich

Over at Emergent Chaos, Adam raises the question of whether we are seeing more data breaches, or just more data breach reporting. His post is inspired by a release from the Identity Theft Resource Center stating that they've already matched the 2007 breach numbers this year.

Personally, I think it's a bit of both, and we're many years away from any accurate statistics for a few reasons:

1. Breaches are underreported. As shown in the TJX case, not every company performs a breach notification (TJX reported, other organizations did not). I know of a case where a payment processor was compromised, records lost for some financial services firms that ran through them, and only 1 of 3-4 of the companies involved performed their breach notification. Let's be clear, they absolutely knew they had a legal requirement to report and that their customer information was breached, and they didn't.
2. Breaches are underdetected. I picked on some of the other companies fleeced along with TJX that later failed to report, but it's reasonable that at least some of them never knew they were breached. I'd say less than 10% of companies with PII even have the means to detect a breach.
3. Breaches do not correlate with fraud. Something else we've discussed here before. In short, there isn't necessary any correlation between a "breach" notification and any actual fraud. Thus the value of breach notification statistics is limited. A lost backup tape may contain 10 million records, yet we don't have a singe case that I can find where a lost tape correlated with fraud. My gut is that hacking attacks result in more fraud, but even that is essentially impossible to prove with today's accounting.
4. There's no national standard for a breach, never mind an international standard. Every jurisdiction has their own definition. While many follow the California standard, many others do not.

Crime statistics are some of the most difficult to gather and normalize on the planet. Cybercrime statistics are even worse.

With all that said I need to go call Bank of America since we just got a breach notification letter from them, but it doesn't reveal which third party lost our information. This is our third letter in the past few years, and we haven't suffered any losses yet.

–Rich

Crime, Communication, and Statistics

By Rich

'I'm not sure if it's the innate human desire to recognize patterns even when they don't exist, or if the stars really do align on occasion, but sometimes a series of random events hit at just the right time to inspire a little thought.

Or maybe I'm just fishing.

This week is an interesting one on the home front. It's slowly emerging that we're having some crime problems in the community. There has been a rash of vehicle break-ins and other light burglary. I found out about it when a board member of our HOA (and former cop) posted in our community forums that we've hired an off-duty Phoenix police officer to patrol our neighborhood, on top of the security company we already have here. We've got a big community center with a pool, so we need a little more security than the average subdivision.

Our community forums are starting to fill up with reports from throughout the community and I highly suspect this recent spree will be ending soon. All 900 homes now have access to suspect descriptions, targets, areas of concern, and so on. We're all locking up tighter and keeping our eyes open. Already some activity was caught on camera and turned over to the police. We know the bad guy's techniques, tactics, and operations. With this many eyeballs looking for them, the odds are low they'll be working around here much longer.

We've had problems for months, and the private security was ineffective. There is just too much territory for them to cover effectively. This spree could have potentially gone on forever, but now that the community is engaged we've moved from relying on 2 people to nearly 900 for our monitoring and defense.

We've taken the edge, just by sharing and talking.

In the security world some interesting tidbits have popped up this week. First came Debix with their fraud numbers, and now Verizon with their forensic investigation's breach report. On a private email list I was slightly critical of Verizon, but I realized I'm just being greedy and wanted more detail. While it could be better, this is some great information to get out there (thanks for making me take a second look, Hoff).

I shouldn't have been critical, because when it comes to data breaches we should be thankful for any moderately reliable stats we can get our hands on.

Between these two reports, a couple of things jumped out at me. First, I think these finally debunk all the insider threat marketing garbage. No one ever really had those numbers; trust me, since I saw my "estimate" from Gartner quoted as a hard number for years. This now aligns with my gut feeling, which is that there are more bad guys on the outside than the inside, although inside attacks can be more devastating under the right circumstances.

To further support this, the Verizon report also indicates that many attacks on the inside (or from partners) are really attacks from the outside that compromised an internal system. This supports my controversial positions on how we should treat the insider threat.

The second major point is that we rarely know where our data is, or if our systems are really configured correctly. Both of these are cited in the report as major sources of breaches- unknown data, unknown systems, and misconfigured systems. This is strongly supported by the root cause analysis work I've done on data breaches (in my data breach presentation; haven't written it in paper/blog form yet). People wonder why I'm such a big fan of DLP. Just think about how much risk you can reduce by scanning your environment for sensitive data in the wrong places.

FInally, it's clear that web applications are a huge problem. Verizon claims web apps were involved in 34% of cases. Again, this supports my conclusion from data breach analysis that links more fraud to application compromises than lost tapes or laptops. The Debix numbers also indicate no higher fraud levels for lost tapes than normal background levels of fraud.

We're on the early edge of building our own neighborhood watch. We're starting to see the first little nibs of hard breach data, and they're already defying conventional wisdom. By communicating more and sharing, we are better able to make informed risk and security decisions. Without this information, the bad guys can keep cruising our neighborhoods with impunity, stealing whatever we accidentally leave in our cars overnight.

–Rich