'Breach cost per record' metric - BUSTED

 

Finally! Data in a report by Cyentia confirms my bias!

I've railed before against biased 'surveys' conducted by market research companies (such as Cyentia) on behalf of their clients (specifically the US gummt's Cybersecurity and Infrastructure Security Agency and Lawrence Livermore National Laboratory, in this case).  

I'm conscious of my own biases (well, some of them anyway!). 

And yet figure 12 in the report, to me, spins a convincing story: 'cost per [compromised] record' is a lousy information security or privacy incident metric, a poor basis on which to determine - well - anything really. 

Even without sophisticated statistics, it is screamingly obvious at a glance that the data points on that graph trend down from left to right - in other words, incidents involving small numbers of breached records are 'disproportionately' costly per record, whereas those involving larger numbers are 'disproportionately' cheap.  

That situation, to me, suggest a more complex relationship - perhaps a fixed cost per incident plus additional factors only loosely related to the number of records potentially compromised (which, by the way, is fairly easily and cheaply determined - a rather convenient 'data point' for the estimations).  

The much-hyped single point 'cost per record' value much vaunted by Ponemon and its clients does not adequately represent the slope of the data nor the spread. To be clear, I rather doubt whether the slope and spread are applicable beyond of the Cyentia survey population (outside the US, for instance) and frankly, given my personal biases, I'm not entirely convinced they are entirely credible within it either (well OK, I'm naturally cynical, guilty as charged).

Bottom line: see the subject of this blog post.

PS  I'm no closer to identifying those 'additional factors' at this point, beyond mere conjecture about the nature of the records disclosed, the corporate situation, the timing and the specific details of the disclosure. Sorry, no simple answers here.