Blame For Breaches, And Where That Gets Us

American Business is suffering an epidemic of data loss. Today (09/09/2014) it is Home Depot that has suffered the latest breach of credit card data. In mid-December 2013, it was Target. Fortunately, we have new notification laws so that we learn about data breaches. In past times, companies kept their losses secret, for many reasons, but primarily to prevent business revenue loss. To blame is human. Embarrassment and shame for mistakes made is also human, and a little bit is a good thing. It acts as an incentive to do better next time, a motivator to improve. But too much fear/shame is an inhibitor. An RSA Conference 2013 presentation on October 2011 SEC Disclosure Requirements for Risk Factors noted that by requiring registrants to disclose their risk factors and incidents, so that the real incident rate can be determined, business can move beyond the fear/shame cycle to realize that "stuff" happens, and deal with it. Because too much fear/shame is paralyzing. But to return to the blame factor, the onus is almost entirely on the target business to prepare and comply with regulatory and legal requirements. Our current InfoSec model is that a company adopt an InfoSec policy, have management support it, perform a risk analysis to determine what assets to protect from which risk factors using these specific controls and perhaps transferring some risks to third parties, implement those controls and transfer the risks, monitor and repeat periodically, and be in compliance. And take the blame when something fails. That model is way too simplistic. And unrealistic. Simplistic because software always has residual bugs and is exploitable. And all of our InfoSec controls, from firewalls to Intrusion Prevention Systems (IPSs) to Authentication and Authorization Mechanisms are software controlled themselves. And the business of businesses is generally not InfoSec, but their primary business. Our model is unrealistic because the motivator to produce software is not to produce quality software that resists exploits. The primary motivator to produce software is a deadline, whether that is to be the first to ship and thereby capture a market or to meet a client schedule. I'm not saying that people purposely write exploitable code, although some do. I'm saying that, because the primary motivator is not to produce quality code, code is shipped with exploits. David Rice was hired in 2011 as Apple's Global Chief of Security. He has a Masters Degree in Information Warfare Systems Engineering from the Navy Postgraduate School in Monterey, CA. His book Geekonomics: The Real Cost of Insecure Software is about the economic incentives for writing software. His quote of Silicon Valley venture capitalist Guy Kawasaki says it all: "Don't worry, be crappy. Just get your product out there". I'm also not saying that everyone ships bad code, but rather that the incentive is to ship code as soon as possible to capture market share. That is over and above the technical issues of software testing and residual bugs. So, American businesses are asked to work with flawed code. They are asked to protect their businesses with security products that have residual bugs. And they are asked to shoulder the blame when they are, inevitably, exploited. What's wrong with this picture? The biggest flaw is that we don't recognize the flaw. We blame the business. It's time we acknowledge that our software has problems, and that the blame should be shared. Yes, the targets need to follow the model, flawed as it is, or they are grossly negligent. But the software suppliers and the security companies share the blame, because their products harbor the exploits, product liability limitations not withstanding. We need to move beyond our model, tone down the blame game, get over the shame, and start reporting every breach, every exploit, so that we can start to understand the true magnitude of the problem and work to fix it. And move beyond merely blaming the targets.