The New School of Information Security » Data Analysis

Sharing Research Data

adam — Mon, 30 Jan 2012 15:45:38 +0000

I wanted to share an article from the November issue of the Public Library of Science, both because it’s interesting reading and because of what it tells us about the state of security research. The paper is “Willingness to Share Research Data Is Related to the Strength of the Evidence and the Quality of Reporting of Statistical Results.” I’ll quote the full abstract, and encourage you to read the entire 6 page paper.

Background
The widespread reluctance to share published research data is often hypothesized to be due to the authors’ fear that reanalysis may expose errors in their work or may produce conclusions that contradict their own. However, these hypotheses have not previously been studied systematically.

Methods and Findings
We related the reluctance to share research data for reanalysis to 1148 statistically significant results reported in 49 papers published in two major psychology journals. We found the reluctance to share data to be associated with weaker evidence (against the null hypothesis of no effect) and a higher prevalence of apparent errors in the reporting of statistical results. The unwillingness to share data was particularly clear when reporting errors had a bearing on statistical significance.

Conclusions
Our findings on the basis of psychological papers suggest that statistical results are particularly hard to verify when reanalysis is more likely to lead to contrasting conclusions. This highlights the importance of establishing mandatory data archiving policies.

Despite the fact that the research was done on papers published in psychology journals, it can teach us a great deal about the state of security research.

First, the full paper is available for free online. Compare and contrast with too many venues in information security.

Second, the paper considers and tests alternative hypotheses:

Although our results are consistent with the notion that the reluctance to share data is generated by the author’s fear that reanalysis will expose errors and lead to opposing views on the results, our results are correlational in nature and so they are open to alternative interpretations. Although the two groups of papers are similar in terms of research fields and designs, it is possible that they differ in other regards. Notably, statistically rigorous researchers may archive their data better and may be more attentive towards statistical power than less statistically rigorous researchers. If so, more statistically rigorous researchers will more promptly share their data, conduct more powerful tests, and so report lower p-values. However, a check of the cell sizes in both categories of papers (see Text S2) did not suggest that statistical power was systematically higher in studies from which data were shared. [Ed: "Text S2" is supplemental data considering the discarded hypothesis.]

But most important, what does it say about the quality of the data we so avariciously hoard in information security? Could it have something to do with higher prevalence of apparent errors?

Probably not. It might surprise you to hear me saying that, but hear me out. We almost never have hypotheses to test, and so our ability to perform statistical re-analysis is almost irrelevant. We’re much for fond of saying things like “It calls the same DLLs as Stuxnet, so it’s clearly also by the Israelis.” Actually, there are several implied hypotheses in there:

No code by different authors calls the same DLL
No code calls any undocumented APIs
Stuxnet DLLs are not documented

Stuxnet being written by the Israelis is clearly not a hypothesis, but a fact, as documented by Nostradamus.

More seriously, read the paper, see how good science is done, and ask if anyone is holding us back but ourselves.

Thanks to Cormac Herley for the pointer.

The New School of Software Engineering?

adam — Wed, 11 Jan 2012 16:33:27 +0000

This is a great video about how much of software engineering runs on folk knowledge about how software is built:

“Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True”

There’s a very strong New School tie here. We need to study what’s being done and how well it works to figure out how to make better software more reliably.

Incidentally, at around 28 minutes in, Wilson mentions Nachi Nagappan‘s work on physical distance versus managerial distance, and then jumps to remote hires at a a startup. While I’m not sure of which paper Wilson is discussing, almost all of Nagappan’s work is done with Microsoft developers and products. As such, both have to be seen in the context of Microsoft’s deep and shared experience in shipping software. By definition, that shared experience doesn’t exist at a startup. And as to the managerial distance issue, it’s satirically discussed here. Assuming that his results generalize is a large jump, and one that I’m not sure I’d make.

More on Authorization Persistence Threats

adam — Fri, 18 Nov 2011 16:16:03 +0000

Wade Baker has a quick response to my “Thoughts on the 2011 DBIR and APT,” including the data that I was unable to extract.

Thanks!

Diginotar Quantitative Analysis (“Black Tulip”)

adam — Tue, 13 Sep 2011 15:12:05 +0000

Following the Diginotar breach, FOX-IT has released analysis and a nifty video showing OCSP requests.

As a result, lots of people are quoting a number of “300,000″.

Cem Paya has a good analysis of what the OCSP numbers mean, what biases might be introduced at “DigiNotar: surveying the damage with OCSP.”

To their credit, FoxIt tried to investigate the extent of the damage by monitoring OCSP logs for users checking on the status of the forged Google certificate. There is a neat YouTube video showing the geographic distribution of locations around the world over time. Unfortunately while this half-baked attempt at forensics makes for great visualization, it presents a very limited picture of impacted users.

Digitar and Fox-IT released enough that a dedicated secondary analyst like Cem can see methodological flaws in what they did. What else could we learn if we had more of the raw observations? When I read the report, I noticed the claim “A number of malicious/hacker software tools was found. These vary from commonly used tools such a the famous Cain & Abel tool to tailor made software.” This claim mixes analysis and observation. The observation is that there was software with which the analyst was not familiar. It may be that it was a perl script or other code that can be easily skimmed to see that it was “tailor made.” It may be that it was just something re-compiled to not match a hash. We don’t know. Similarly, the report claims (4.1) “In at least one script, fingerprints from the hacker are left on purpose, which were also found in the Comodo breach investigation of March 2011.” Really? On purpose? Perhaps the fingerprints were inserted as a matter of dis-information. Perhaps the Fox-IT analyst called the intruder on the phone, and he owned up to it. We don’t know.

I want to be clear that I don’t mean to be picking on Fox-IT here. My understanding is that the report they prepped came out incredibly quickly, and kudos to them for that. I’ve cherry picked two areas where I can ask for better editing, but I’m very aware that that editing comes at a cost in timeliness.

Cem’s article is very much worth reading, as is the Fox-IT report. But Cem’s analysis helps illustrate a theme of the New School, which is that we need diverse perspectives and analysis brought to bear on each report. The more data we see, the more we can learn from it. No single analysis will tell us everything we might learn. (I made a similar point here.)

I am left with a question for Cem, which I would have added to his post, but couldn’t comment there. My question is, having given all that thought to all the biases, what do you think is the probably true number (or range) of affected people?

Securosis goes New School

Russell — Wed, 10 Aug 2011 20:12:42 +0000

The fine folks at Securosis are starting a blog series on “Fact-based Network Security: Metrics and the Pursuit of Prioritization“, starting in a couple of weeks. Sounds pretty New School to me! I suggest that you all check it out and participate in the dialog. Should be interesting and thought provoking.

[Edit -- fixed my mispelling of company name. D'oh!]

Fixes to Wysopal’s Application Security Debt Metric

Russell — Sat, 05 Mar 2011 09:47:27 +0000

In two recent blog posts (here and here), Chris Wysopal (CTO of Veracode) proposed a metric called “Application Security Debt”. I like the general idea, but I have found some problems in his method. In this post, I suggest corrections that will be both more credible and more accurate, at least for half of the formula. The second half is harder to do right and needs more thinking.

Overview

Application Security Debt is based on the concept of “technical debt” proposed by Ward Cunningham (a programmer who developed the first wiki program): describes it like this:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Chris adds:

The cost of technical debt is the time and money it will take to rewrite the poor code after you ship and bring it back to the quality required to maintain the software over the long haul.

Here is Chris’ summary of Application Security Debt:

Security debt is similar to technical debt. Both debts are design and implementation constructions that have negative aspects that aggregate over time and the code must be re-worked to get out of debt. Security debt is based on the latent vulnerabilities within an application. Application interest rates are the real world factors outside of the control of the software development team that lead to vulnerabilities having real cost. These factors include the cost of a security breach and attacker motivation to discover and exploit the latent vulnerabilities.

Chris’ second post describes a financial model that estimates the cost of Application Security Debt. Framing the metric in financial terms will presumably help managers compare the cost of the “debt” to the cost of developing more secure software or costs of fixing the vulnerabilities. (Note: Veracode provides a range of application security testing services, so they have an interest in economically justifying their services. This isn’t a criticism of Veracode, Chris, or his proposal. Just a reality.)

Chris’ model is focused on the simplest case where the application developer and application user is the same organization, so that it bears the costs of development, maintenance, and also any security breaches that result. Starting with the simplest case is a great idea when proposing a new method. So far so good.

Chris defines his financial model this way:

The basic financial model for security debt is monetary risk that can be expressed as expected loss. The formula for expected loss is event likelihood X impact in dollars. Event likelihood is based on the makeup of vulnerabilities in the application and the likelihood that the vulnerabilities will be discovered and exploited. The impact is the cost of a security breach based on an exploit of one of those vulnerabilities. [Emphasis in original]

This is, of course, a version of the bottom-up Annualized Loss Expectancy (ALE) formula for individual risk elements:

ALE = Single Loss Expectancy X Annual Rate of Occurrence

(Mike Rothman recently crapped on all “risk metrics” by lumping them all into the ALE formula. I’ll critique ALE and Mike’s post in a separate blog post.)

ALE issues aside, I think Chris is making mistakes in his definition of Application Security Debt that will lead to serious confusion.

Debt = Expected Principal + Interest Costs

Chris made a mistake when he defines monetary value of the Application Security Debt as expected loss due to security breaches. Instead, the ‘Principal’ part of the debt formula is the cost of fixing security problems beyond what is budgeted. Chris had it right in his summary in the first article:

The cost of technical debt is the time and money it will take to rewrite the poor code after you ship and bring it back to the quality required to maintain the software over the long haul.

Expected losses are in the category of “Interest Costs” as Chris said in his summary:

Application interest rates are the real world factors outside of the control of the software development team that lead to vulnerabilities having real cost.

Putting this together in simple language:

“Application Security Debt is a ‘loan’ with variable principal which could range from 0% to 100% of your original project costs. The ‘principal’ is what you’ll eventually have to pay to fix security bugs or rewrite the code. It also has varying and uncertain ‘interest costs’, which are the costs of security breaches due to these vulnerabilities. This includes the possibility of the mother-of-all balloon payments (i.e. a huge loss event).”

The good news is that Expected Principal is relatively easy to estimate with good accuracy and without a lot of outside data. The not-so-good-news is that Interest Cost is a bear to estimate.

Estimating ‘Expected Principal’

For simplicity, let’s assume that cost of fixing code (above the budgeted costs) occurs in discrete increments, F:

Zero (i.e. your debt is ‘forgiven’)
Minor fixes and patches (‘Principal’ = 10% increase in project cost)
Major fixes and patches (‘Principal’ = 25% increase in project cost)
Substantial rewrite (‘Principal’ = 50% increase in project cost)
Total rewrite (‘Principal’ = 100% increase in project cost, or more)

Thus, the best case is that you owe no principal and the worst case is that you owe principal equal to the entire cost of the project. You could include other factors such as external costs of schedule delays, costs of rehiring your programmers after you fire them all , or what ever. My point is that these costs are not open-ended, but are a multiplier on your original development costs.

The Expected Principal (EP) is equal to each of these cost scenarios multiplied by their probability of management choosing that option:

For example, if the original cost of the application development project is $1 million, and there is 5% chance of Zero costs, 80% of Minor code fix costs, and 15% chance of Substantial rewrite costs, then the Expected Principal would be $155,000, or 16% of the original cost.

This is important: Expected Principal is ultimately determined by management decisions and ‘threshold of pain’. This means that the value of p(F), above, is a subjective probability. It would be an ideal metric to estimate using prediction markets (PMs). (PMs have been used successfully in software development to estimate shipment dates and defect rates, for example.)

Another implication: you don’t need to accurately forecast future loss events or their economic impact to get a decent estimate of Expected Principal. Instead, you only need to estimate the Interest Costs very roughly to determine which code fix scenario is most likely. You could even estimate p(F) by setting thresholds for the number and severity of vulnerabilities discovered by certain levels of effort. Better, you could combine these methods to ‘triangulate’ on estimates of p(F).

To calibrate these subjective probability estimates, it would be very helpful to collect historical data on the % of applications that have some level of rewrite or schedule delay due to security problems. (Hint hint!)

Estimating ‘Interest Costs’ on the Debt will be Hard

The second part of the Application Security Debt formula is ‘Interest Costs’. This is where things get hairy. All the members of the ALE family of risk calculations have a similar flaws: 1) prodigious data requirements and 2) propagation of uncertainty through the calculations. Furthermore, some suffer by using only mean values and ignoring extreme values (i.e. the “tails” of the probability distribution curves).

Chris acknowledges these issues, at least the requirement for more and better data:

Now you are probably thinking that this is getting a little tenuous and it is. We need better data on likelihood type and likelihood of an application breach by industry and other factors like company size.

Data issues aside, I think there are flaws in his use of ALE and calculation methods. Here’s one thought experiment to show how it could lead to the wrong conclusions, in my opinion.

Let’s use Chris’ ‘baseline expected loss’ table, where he calculates the expected loss for each type of vulnerability. Imagine that we are comparing two similar applications, A and B. Assume that each project is expected to have the same number of vulnerabilities, five each. Let’s say the development cost of each project is $1 million. Application A has five SQL injection vulnerabilities while application B has one SQL Injection vulnerability and four Remote File Inclusion vulnerabilities. Doing the calculations:

A’s expected losses = $19,220,000
B’s expected losses = $5,074,080

Does project A really have four times more risk than project B? Probably not. From what I know, the number of vulnerabilities in an application is not proportional to the likelihood that the application will be breached. Instead, I’d guess that the likelihood of being breached is a function of where the application is in the IT architecture, how accessible it is, how important it is to attackers, etc.

Also, there’s the ‘weakest link’ effect: “given enough random attackers or one persistent attacker, it only takes one vulnerability to lead to a breach”. Assuming all SQL Injection vulnerabilities are equally discoverable and equally exploitable, then we should estimate that application B with one SQL Injection vulnerability is just as likely to get breached as application A with five, all other things being equal.

(I confess I’m not an expert in application security or vulnerability analysis, so these comments are my interpretation of what others have written or said.)

Even if my logic here is flawed somewhat, my main point is that the relation between number of vulnerabilities and likelihood of being breached is non-linear and it may even be indeterminate if contextual factors dominate.

This example also hints at another severe weakness in the ALE method – it ignores correlation and dependence between risk elements and factors. We know from forensic analysis and the DBIR that severe security breaches involve a sequence of exploits and attacks. This means that the likelihood of breach in one application is dependent on the likelihood of breach in other applications and systems. An application might appear unimportant, but it might be a stepping-stone to other applications, databases, and networks.

It’s hard to account for all these factors and influences together without some sort of over-arching model for enterprise-level information security and risk. Basically, you are looking for the ‘risk contribution’ of those specific application vulnerabilities to total costs, now and in the uncertain future. Formally, the ‘Interest Cost’ for any given set of application vulnerabilities is the difference between the Total Cost of Security (TCoS) in two possible worlds: World 1) application A has X vulnerabilities, vs. World 2) application A does not have X vulnerabilities (or if application A is not deployed at all).

What we really need are some short-cut approximations for this that doesn’t require a complete data set and risk estimates for the whole enterprise. One approach I’m interested is in using modern AI methods (data mining, machine learning, inference methods). This is on-going research.

Summary

I’m glad Chris proposed his Application Security Debt metric. I hope my post has been helpful in correcting some of the errors, as I see them. The good news is that the “Expected Principal” component of the metric looks like it can be estimated fairly easily and with good accuracy. On the other hand, the “Interest Cost” component needs a lot of work. I’m happy to collaborate with Chris or anyone else who wants to work on this.

Infosec’s Flu

adam — Fri, 04 Feb 2011 16:53:59 +0000

In “Close Look at a Flu Outbreak Upends Some Common Wisdom,” Nicholas Bakalar writes:

If you or your child came down with influenza during the H1N1, or swine flu, outbreak in 2009, it may not have happened the way you thought it did.

A new study of a 2009 epidemic at a school in Pennsylvania has found that children most likely did not catch it by sitting near an infected classmate, and that adults who got sick were probably not infected by their own children.

Closing the school after the epidemic was under way did little to slow the rate of transmission, the study found, and the most common way the disease spread was a through child’s network of friends.

The work he discusses is “Role of social networks in shaping disease transmission during a community outbreak of 2009
H1N1 pandemic influenza” by Simon Cauchemeza, Achuyt Bhattaraib, Tiffany L. Marchbanksc, Ryan P. Faganb, Stephen Ostroffc, Neil M. Fergusona, David Swerdlowb, and the Pennsylvania H1N1 working group.

The first thing that comes to mind is that closing schools is a best practice. It’s something that makes so much sense that it’s hard to argue against, even if it does no good. The next thing is look at what happens when they have data available to them. They can study their prescriptions and test to see if they did any good. But note how detailed the data is: social graphs, seating charts. This isn’t something we would obviously get from more detailed breach notices. It’s going to require in-depth investigations, and investigators who talk about their methods. VERIS is a step in this direction, and I’m looking forward to seeing critiques or even competitors that can help us move forward and learn.

But the data we have is the data we have, and while we work to get more, there’s a good deal that we can probably learn from what’s out there. We just have to be willing to ask if our practices really work.

Dark Reading Virtual Event & Evidence-Based Risk Management

alex — Thu, 03 Feb 2011 13:54:18 +0000

Hey, I know it’s late notice, but I’ll be speaking at 10:30 EST today on EBRM and the Verizon DBIR:

https://www.techwebonlineevents.com/ars/eventregistration.do?mode=eventreg&F=1002809&K=CAA1BC&tab=agenda

Alex

Another critique of Ponemon’s method for estimating ‘cost of data breach’

Russell — Wed, 26 Jan 2011 01:55:14 +0000

Adam just posted is general critiques of the annual US Cost of Data Breach Study. I agree with his critique about survey methods, but I have more fundamental objections to their methods used to estimate ‘indirect costs’ due to lost customers (‘abnormal churn’) and the cost of replacing them (‘customer acquisition costs’).

A noble effort, but…

Before I start chopping it up, let me say that I think their annual survey is a good effort and it’s positive that they can get sponsorship and also readership for the results. I think they have good intentions and try to give a fair, balanced, and reasonable estimate. Our field would be better off if there were similar data gathering efforts in other areas of InfoSec. I also don’t believe that any of the errors are due to intentions to ‘spin’ or mislead. It looks like they didn’t have sufficient expertise on their team in business finance, marketing analysis, and economics.

But I see some serious problems with their methods. This is a big deal since ‘indirect costs’ make up a majority (68%) of their estimate of total costs.

Problem #1: A fog of buzz words

If their data and analysis were bulletproof, then maybe we could forgive sloppy use of terms. But it isn’t bulletproof and their use of terms is actually misleading because it gives the impression that the method is well established and well executed when it really isn’t. Furthermore, it’s a sign that whoever is doing this part of the analysis doesn’t know what they are talking about. Examples:

“The survey design relied upon a shadow costing method used in applied economic research.” (p. 36) — There is no such method as ‘shadow costing’. Do a web search if you doubt me. The only examples of ‘shadow costing’ are economic studies that use ‘shadow prices‘ multiplied by input quantities to derive ‘shadow costs’ for certain manufacturing or service process. Having just completed a Mathematical Economics class last semester, I can assure you that the Ponemon method has nothing to do with shadow prices or shadow costs.
“Utilizing activity-based costing…” (p. 3) and “The diagram below illustrates the activity-based costing schema…” (p. 36) — They do not use activity-based costing. Activity-based costing (ABC) is a way of allocating overhead costs by measuring some ‘activity’ in operations that are thought to drive those overhead costs. The ratio of ‘activity’ for each business unit to the total is used to allocate the overhead cost to that business unit (or product line or customer segment or what ever). You can read more about ABC here and here. How big a flub is this? Big. It’s like labeling a signature-based AV software as an ‘expert system’. Anyone who uttered such a statement would immediately be dismissed by security experts. What ever the Ponemon method is, it’s not ABC. Just because costs are related to activities does not mean you are doing activity-based costing.
“…most companies experience opportunity costs associated with a breach incident...” — No, these aren’t ‘opportunity costs’. The term ‘opportunity cost‘ has very specific meaning in microeconomics. Basically, an opportunity cost is the cost of giving up your next-best alternative when you make a decision. They misuse the term here to refer to costs that expected in the future, i.e. beyond the historical frame of the breach incident and post-incident remediation. Their use of the term here is just sloppy and could easily mislead someone who doesn’t know economics.

Problem #2: Mixing accounting costs with economic costs

This is a subtle but fundamental problem, and it’s why people get degrees in accounting and economics. Accounting costs are those that appear in a financial statement somewhere and follow specific costing rules, e.g. GAAP. They have already occurred (historical costs) or they are forecasted to occur (pro forma costs). In the Ponemon method, they list four categories of accounting costs:

Detection or discovery
Escalation
Notification
Ex-post response

Now it’s probably true that most organizations do not have explicit accounts for these costs so they have to be derived from other accounting costs. But it’s pretty easy to slice and dice accounting data (i.e. general ledger entries) to get decent estimates of these costs. It’s also possible estimate costs by using per-resource costs (labor cost per hour) multiplied by the usage of those resources (hours to resolve an incident). In the Ponemon survey, they ask their point-of-contact for their estimate of these costs. That’s probably OK, given that the point-of-contact is a privacy/security person directly involved in the incident.

But then they mix in future economic costs (what they mislabel as ‘opportunity costs’):

Turnover intentions of existing customers
Diminished new customer acquisition

(Leave aside for a moment that they are asking about “intentions” of customers to defect. Adam discussed this in his post.)

These are both economic costs. (See this slide deck, slide #2. The wikipedia article on this topic is not good.) Basically, economic costs are all in the future. There is no such thing as ‘historical economic costs’. Only cash flows count in economic costs — no ‘intangibles’, no depreciation, no ‘good will’. Those can only be included in the form of future cash flows discounted for time and risk (and uncertainty). Economic costs include opportunity costs (see above), which are the cash flows associated with the next-best alternative. However, opportunity costs will never appear on a financial statement, now or in any future. Economic costs are incurred when the commitment is made, not when they are recognized in the accounting system.

Most important: All cash flows are discounted for the time value of money and the riskiness of the cash flow. This feature is essential for rational deicsion-making over time and over risky alternatives, but it also guarantees that no estimate of economic costs will ever equal the corresponding accounting costs because accounting systems to not adjust for the time value of money or risk. Finally, a full estimate of economic costs includes the present value of ‘real options’ and should be adjusted for risk (i.e. derating by using the costs of insuring against unexpected/extreme events, cost of lowered credit rating, etc.).

The element of their method that specifically invokes economic cost is ‘lifetime value of customers’ (LTV). In their method, the cost associated with lost customers is estimated by multiplying the % of breached customer records that will defect (‘abnormal customer churn rate’) multiplied by LTV. (LTV originated in direct marketing in the 1980s. Wikipedia has a decent article that explains it. Here’s a good demonstration.) LTV is a net present value, discounted by the cost of capital associated with the riskiness of the cash flow. It’s an economic profit, not an accounting profit.

Putting this all together, either the costing method should use only accounting costs (historical and/or pro forma) or it should only use economic costs (prospective discounted cash flows, risk-adjusted). Otherwise, the numbers don’t add up, literally.

Problem #3 : Decision polices matter

(i.e cheap short-sighted bastards can have lower costs than prudent socially responsible managers)
Here’s another problem with mixing accounting costs with economic costs. Let me illustrate this with a story. There are two companies — Cheap Bastard, Inc. (CBI) and Nice Guys R Us (NGRS). CBI has decision policies to spend as little as possible on InfoSec, especially in incident detection and incident response. They push all liability onto their customers, suppliers, and contractors. They systematically downplay evidence of breaches, and downplay the severity or costs of breaches. They avoid forensic analysis if they can get away with it. And so on.

In contrast, NGRS puts a lot of attention on pro-active security and detection and goes out of it’s way to mitigate the costs of insecurity on it’s ecosystem. They are especially eager to spend money post-breach to restore public trust and to learn from the event to get at root causes.

How would CBI and NGRS show up in the Ponemon survey? My guess is that NGRS would have cost per record of 2X or 3X greater than CBI, primarily because CBI will have much lower accounting costs (as covered by the survey) by decision policy. It’s also likely because CBI can ‘safely’ ignore the probable future costs of their rapacious behavior (i.e. class action lawsuits, regulatory penalties, even larger security breaches). I put ‘safely’ in quotes because such corporate behavior is only safe until you get caught or get screwed.

I don’t see a way around this if you only use accounting costs. If you use a sufficiently broad framework for economic costs, then you stand a chance of understanding the ‘total costs’ that exposes the riskiness of CBI’s decision policy.

Problem #4 : Do respondents really know anything about customer LTV or ‘churn’ intentions?

I’m surprised that no one has brought this up before. As someone who has calculated and published LTV metrics for a business unit, I can say with some confidence that almost no one who didn’t read those reports would have been able to guess the LTV of customers, including accounting people who knew about the cost and revenue categories but never put them together into LTV. SWAGs (as in def. 5) were could be off by an order of magnitude.

My opinion is that asking a privacy/security/incident response specialist to estimate LTV is fundamentally flawed unless that person has access to their own company’s management reports that include LTV. It might be possible to elicit useful estimates from them after their estimates are calibrated through exercises, including exercises that estimate the weighted average cost of capital, average lifetime of a customer, acquisition costs, retention costs, etc.

Same goes for ‘churn’ rate (percentage of customers who leave because their records were breached). To estimate ‘abnormal churn’ due to the breach, the point-of-contact would need to know something about ‘normal churn rate’ and, as Adam says in his post, the variability of churn rate. If churn rate varies widely from year to year, then a small increase in churn due to a data breach would be washed out by the other factors driving variability.

It would be much more useful to find out if the company increased their marketing budget as a direct consequence of a given data breach. If they did, then this would be credible evidence that the number and value of lost customers was great enough for the company to change it’s spending decisions.

Problem #5: Leaving out significant cost categories

This problem may be bigger than all the others combined. If they left out major categories of cost, then their estimate of cost per breach could be off by 50% or more.

To answer this question, you first need to decide between estimating accounting costs vs. estimating economic costs. Every economist and every B-school professor will advise you to estimate economic costs. It may be useful to analyze historical accounting costs as a way to estimate future economic costs, but that is a separate exercise.

As an economic cost analysis, it might be best to frame the decisions this way:

Given a breach of customer data of size X records (same size as historical breach), how would the firm’s economic costs change vs. no breach?

I’ll point out two categories of cost that this analysis would include that are currently excluded in the Ponemon survey.

Cost of additional spending on security
If a firm incurs incremental spending on security due to a breach, shouldn’t those costs be included in the ‘cost of a data breach’? This goes back to my story about fictional companies CBI and NGRU, above. If CBI is likely to spend more to fix their crappy security in the future if they experience a large breach today, then they will be forced to ‘pay the piper’ in economic terms and their decision policy of spending as little as possible won’t help them avoid the full costs of data breaches. This will also capture the cost of half-measures, since trying to get off cheap on the security upgrade will still show up as higher expected costs for future breaches.

Of course, this raises sensitive political issues with respondents to the survey. They may be reluctant to answer questions about actual spending on improvements to security or, even more, to speculate about possible future costs. For example, what if a company’s outsourcing strategy is hopelessly insecure and the firm is forced to reverse those decisions and insource those processes. What if a company is forced to exit a line of business because the security risks and costs are too high? What if a data breach leads to process changes that diminish or eliminate their key competitive advantage?

Factoring these costs could increase the cost of a breach by 0.5X to 10X. I would make it much harder to do cross-company and cross-industry comparisons. But wouldn’t it make the true economic costs of data breaches more relevant to management decision-making?

Social costs
The other ‘elephant in the room’ is the cost to consumers or employees for having their private data breached. Add these all up and you get ‘social cost’, or appropriately adjusted, ’social welfare‘. I understand that the Ponemon survey is estimating only costs that are incurred by a single organization that experiences the breach, not by any other stakeholders in that firm’s ecosystem.

There are plenty of studies on the direct and indirect costs of identity theft and the perceived costs of breaches of privacy. Drawing on these studies might make it possible to estimate the social cost of a breach. Then the estimation question is “What portion of social cost will the firm have to bear?”

The answer to this question depends on firm policy (see CBI and NGRU story, above), the legal system, the regulatory system, and also the legislative system. Basically, if a firm or collection of firms consistently and egregiously impose large costs on their customers or employees, then one or more of these other social/political mechanisms might kick in to impose an ‘equity remedy’.

The most immediate remedy, from the American firm’s point of view, is a class action lawsuit. Of course, estimating the likelihood of getting sued, the damages sought, and the likelihood of losing such a suit is risky business . But just because it’s difficult to estimate with precision should it be excluded?

Again, including this cost category might increase the cost per breach by 2X to 10X in some cases. But it might also shift management attention to crucial questions such as “What is our role in our value network regarding information security and risk?”

Problem #6: Unsupportable inferences

Given that their survey method is not statistically robust (see p. 33), they do not have sufficient confidence to make the inferences summarized on p. 28. I won’t go through these one by one, but anyone who has done statistical sampling and inference knows how sample size and variability affect confidence intervals. If the difference in question does not exceed the confidence interval, then you cannot support the inference from the data. The best they can do is say, “we say X% of companies report Y, vs. A% of companies reporting B. This suggests that…”. All such suggestions would then need to be subjected to additional tests.

Problem #7: Is ‘Cost per Record’ the best measure?

It appears that only a few costs truly vary by the number of records breached. These include costs of ‘notification’ and some of ‘ex-post costs’. But ‘discovery’, ‘escalation’, and ‘indirect costs’ are mostly independent of size of breach measured by number of records. Some might be fixed costs that are independent of the size of breach. Some might be increasing functions, perhaps relative to some threshold of that defines ‘big’ or ‘material’ (to use the accountant’s term).

This problem may not be significant compared to the others. I just think it needs to be justified by comparing it to alternative formulations.

Summary

The summary result ($204 per record) reported in the Ponemon survey is not reliable. No one should rely on the absolute value of this measure. Some of the relative measures might be informative, especially the direct costs that the point-of-contact respondents are qualified to answer. Trend analysis might be somewhat informative. None of the recommendations reported (i.e. the value of hiring outside IT security consultants) can be supported by statistically significant inferences.

To get a reliable measure of Cost of a Data Breach will require substantial revision to the survey instrument, sampling method, analysis methods, and reliability controls. I’m guessing that this is beyond the appetite of PGP, the sponsor of the survey.

Call to action

What would it take to launch a Version 2.0 of this study with more robust methods and a stronger team of experts to execute it and analyze the results? There’s no mystery about how to do Version 2.0. The only obstical is resources and commitment.

“Cost of a Near-miss Data Breach“>

A critique of Ponemon Institute methodology for “churn”

adam — Tue, 25 Jan 2011 16:56:10 +0000

Both Dissent and George Hulme took issue with my post Thursday, and pointed to the Ponemon U.S. Cost of a Data Breach Study, which says:

Average abnormal churn rates across all incidents in the study were slightly higher than last year (from 3.6 percent in 2008 to 3.7 percent in 2009), which was measured by the loss of customers who were directly affected by the data breach event (i.e., typically those receiving notification). The industries with the highest churn rate were pharmaceuticals, communications and healthcare (all at 6 percent), followed by financial services and services (both at 5 percent.)

Some comments:

126 of the hundreds of organizations that suffered a breach were selected (no word on how) to receive a survey. 45 responded, which might be a decent response rate, but we need to know how the 126 were selected from the set of breached entities.
We don’t understand the baseline for customer churn. What is normal turnover? Is it the median for the last 3 years for that company? The mean for the sector last year? If we knew how normal turnover was defined, and its variance, then we could ask questions about what abnormal means. Is it the difference between management estimates and prior years? Is it the difference between a standard deviation above the mean for the sector for the past 3 years and the observed?
Most importantly, it’s not an actual measure of customer churn. The report states that it measured not actual customer loss, but the results of a survey that asked for:

The estimated number of customers who will most likely terminate their relationship as a result of the breach incident. The incremental loss is abnormal turnover attributable to the breach incident. This number is an annual percentage, which is based on estimates provided by management during the benchmark interview process. [Emphasis added.]

The report has other issues, and I encourage readers to examine its claims and evidence closely. I encourage this in general, it’s not a comment unique to the Ponemon report. Some examples from a number of additional surveys, that George Hulme raised in argment in this blog post:

Briefly, the CMO council found concern about security, not any knowledge of breaches. Forrester showed that some folks are scared to shop online, which means brand doesn’t matter, or they’d shop online from trusted brands. Javelin reports 40% of consumers reporting that their relationship “changed,” and 30% reporting a choice to not purchase from the organization again. Which is at odds with even the most ‘consumer-concerned’ estimates from Ponemon, and is aligned with the idea that surveys are hard to do well.