One thing those of us who've spent any time in the security business know is that you either learn to deal with a flexible schedule or you change professions. Dilbert called them "unplanned emergencies" but whatever you call them, they are a fact of our life. So here I am, sitting in the
Before heading to the airport, I was able to sit in on the first hour and hit Rod Beckstrom's "The Economics of Networks (and Beckstrom's Law)" presentation. Rod is the former Director of the
The thrust of the Rod's presentation today was to introduce Beckstrom's Law and establish that while economics of networks do matter, rather than use the number nodes on a network to determine value, the real key is the number of transactions conducted and the value added by each. Beckstrom's Law solves the valuation problem by looking at how valuable the network is to each individual user. One of the key, and hard, things about Beckstrom's Law that Rod readily points out is that you must either have access to the transaction data or be able measure it. Depending upon the size of your organization, wrapping your brain around that might be a challenge.
Rod posits that while the economics of the basic security model are Value = Benefits - Cost, the more fundamental risk management model calls for minimizing costs which requires additional variables that include SI (Security Investment) and L (Losses) and the new equation V = B - C' - SI - L. It's a little too detailed for this blog but you can get the Wikipedia description here wikipedia - Beckstroms Law and see the entire presentation here The Economics of Networks If you spend some time with Beckstrom's Law and have thoughts or comments, I'm sure Rod would be happy to hear from you.
I really like the concept of Beckstrom's Law. SI+L being the cost of risk management, and accounting for the 80/20 rule / the exponential nature of security costs, but I have one small problem with this in practice. In certain cases, you can't measure L with any real accuracy. For example, if L is the value of lost transactions as a result of downtime, it's pretty concrete math. However, if L is the value of sensitive data, I don't think we have enough of a precedent set to accurately put a dollar figure on it. Data value is an entirely subjective number, no matter how it's derived.
Additionally, that number doesn't "scale" the same way in both those scenarios. In the downtime example, you can reduce your downtime with redundancy at various levels in a reasonably linear fashion. But one data breach, and all X-million of your records are out the door. The ONLY way you can reduce L is by making your assets (data) unavailable (off-line), so you don't have as much available to lose. Wasn't that the way it was a long time ago (mainframes) and lose that battle to agile businesses (web enabled client-server environments)?