Talking with David Rice; insecure software implications, regulation, vendors, making change and other things….

Posted on July 29th, 2008 by Drazen Drazic

David Rice is an internationally recognised information security professional and author of the critically acclaimed book, “Geekonomics: The Real Cost of Insecure Software.”  For a decade he has advised, counseled, and defended global IT networks for government and private industry. David has been awarded by the U.S. Department of Defense for “significant contributions” advancing security of critical national infrastructure and global networks. He is a frequent speaker at information security conferences and currently Director of The Monterey Group.

I had a chance to talk with David recently and I hope you enjoy the read.

———————————————————————————-

BorB: Thank you for taking the time for a chat David. I thoroughly enjoyed the book and would recommend it to everyone. What’s the feedback been like from the industry and non-industry (consumers) in general?

DR: Thank you for the opportunity to join the discussion on your blog. Feedback from the information security industry has been overwhelmingly positive. Defending against an unrelenting stream of software vulnerabilities is simply unsustainable. It also happens to be ridiculously expensive. I think people get that point. Software manufacturers and security vendors have led us into a cul-de-sac that we have been wandering around in for a few years, and the frustration is palpable. I think approaching insecure software from an economic perspective has started opening doors that lead out of the cul-de-sac and there is a feeling of hope in that.

The response from outside the information security industry, particularly consumers, has been a mixture of enlightenment, shock, and dismay. For example, a U.S. government representative stated to me, “I can’t put [the book] down. It’s incredible because I’ve never really thought about things this way before.” On a recent radio interview the host asked (rather desperately I might add), “Why isn’t this stuff [cyber attacks] being reported? What do we do?” By the tone of his voice, I could tell he was truly disturbed as well as surprised. It was as if someone told him cigarettes cause lung cancer, manufacturing creates pollution, or fatty foods cause heart disease. Yes, indeed, software can have significant private and social costs also.

On the whole, I think these reactions are healthy and normal. Some people are getting concerned, and some angry. These reactions, and those like them, are understandable and I take such reactions as a good sign. It means that listeners are re-adjusting their viewpoints based on the information presented to them. In the end, I don’t think if we inside the security profession really comprehend just how far behind the rest of the populace is in understanding the issues of cyber security.

BorB: Most of the time I feel the Information Security industry is very insular. We discuss issues and debate amongst ourselves, we target important news and messages to ourselves, and the outside world really knows little about the problems in technology that we as a society face. Was that a key reason for the book being targeted at everyone as opposed to falling into that industry black hole so full of great messages and ideas?

DR: Yes. People – regular, normal, “non-techie” people – need to know and understand how the software market is affecting them. At base, insecure software is a public policy issue; insecure software enables all sorts of highly foreseeable malicious activities. The public needs to know about the consequences of poorly written, insecure software in a manner and voice that, I hope, makes the issue approachable. This is key to changing status quo in the software market and the defining aspect why I wrote Geekonomics.

We, as security professionals, should and must have heated debates about the security challenges technology imposes on our society as well as the possible solutions. In some instances, such debate might best be had in isolated, confined, and even insular groups. But we must also have an equally determined willingness to communicate meaningfully, simply, and clearly with those outside of our group that will never, and will never want to be, technology experts. We risk becoming irrelevant if we fail to comprehend and practice this.

What I particularly like about looking at cyber security from an economic perspective is that an economic argument tends to act as a middle ground, a neutral place where both industry professionals and non-industry readers can look at look at the issue without having to understand the incredible complexity of software itself. And that’s the point. We don’t need to understand insecure software in its entirety; we just need to get humans to stop creating the stuff. It’s a simple message espoused many times over in the field of economics regarding myriad topics. More importantly, it is a message that is understandable for the expert and non-expert alike. We might not know everything about the complexities of software, or global climate, or rhinoceros habitat for that matter, but as humans we know people and have a pretty good idea what drives individuals towards or away from certain behaviors.

Incentives are something even a two-year old understands.

BorB: Quite a few industry “specialists” argue that we’re always going to have software full of vulnerabilities and bugs and that we just need to get used to it and compensate as best we can. (eg; don’t buy bad software, look at open source and freeware, accept that FWs, IDS/IPS, anti-virus and other anti-badware will always be part of life, etc). What are your thoughts on that?

DR: This viewpoint is defeatist. It is also short sighted. Worst of all, it is unsustainable. It is true that perfect software is not possible and that software vulnerabilities are, and will be, an inevitable part of software manufacturing, but that does not mean we can do nothing to stop the issue directly.

Take for instance sulfur dioxide emissions in the 1970s. There was so much of it in the atmosphere because of coal-fired power plants that scientists thought we were entering the next Ice Age. If we said collectively as a society, “well, sulfur dioxide emissions are just an inevitable part of producing electricity, deal with it,” that would be equally as defeatist, short sighted, and unsustainable as are statements about insecure software. In fact, we were able to substantially reduce the amount of sulfur dioxide in the atmosphere by taxing coal-fired power plants extensively. It proved so successful that now we have a warming planet and carbon emissions to worry about. Irony.

The point here is that we have found very creative ways to deal with very unique and complex problems such as pollution, nuclear power, pharmaceuticals, and so on. It is true that software is perhaps some of the most complex stuff we’ve ever created, but that does not mean we are irrevocably handicapped because of it.

As your question highlights, and what I find most disturbing, is the continued protection software manufacturers seem to enjoy even by security practitioners…as if somehow software manufacturers are untouchable, unmovable, or unstoppable in their behavior. They are not. They have incentives; some implicit, some explicit, but incentives nonetheless. It is a policy decision on the part of governments everywhere to allow software manufacturers to behave as they do, to put their citizens at risk, to threaten their own infrastructures. To change the manufacturer’s behavior requires a change in policy. It’s just that simple. And just that difficult.

In the end, you get what you tolerate.

BorB: I recently wrote in a post that little is changing. We are not learning from the lessons of the past. There are few, if any new technologies that exist today, that we have great faith and trust in as being secure now, and expecting them to continue to be secure in the future. Any solutions to even basic security issues need a starting point and a significant change to current thinking, and even then, it will takes years to see the impacts of this. What are your thoughts on this? Are we seeing anything at present to make us more confident of the future?

DR: It is true that it takes years to see the positive impacts of a change of mindset. And we are in the unfortunate position of repeating many old lessons.

At base, human history is a collection of exhaustive, expensive, and protracted engagements; only the relentless survive and have a chance at succeeding (notice no guarantee here). Confronting some of our most complex problems like highway safety, nuclear proliferation, or insecure software is painful, difficult, complicated, and troublesome. Human endeavors of any significance are like this. But we must do it. The inertia of culture and status quo is difficult to overcome, but overcome it we can; otherwise, we would not have the better parts of the world we enjoy today.

I believe the technology space is no different. We are just a little dazed and bewildered by all the changes technology has introduced so quickly and on such a grand scale. For every change we react to, another two or three rapidly appear.

I do see sparks of hope emerging. In the United States some members of government are beginning to understand the problem and are willing to start discussing how to approach insecure software from a policy perspective. On the technology front, companies like Ounce, Fortify, and Veracode are beginning to give software buyers an automated method of evaluating assurance levels of software. While not complete in and of themselves, these solutions are, as I stated, “sparks” that can help us progress down paths that were once not easily open to us.

As for the larger issue of cyber security, which software assurance is only a part of, society has a lot of adjusting to do. The Internet is a new environment for many still, and many more to come. There is a learning curve that must be confronted. It took the United States almost 80 years to develop the highway system we know and enjoy today. Nearly $400 billion was spent on this endeavor with hundreds of thousands of lives lost. As this shows, learning how to govern and navigate a new environment is expensive. Failing to learn even more so.

BorB: Related to the previous questions somewhat; more and more we are seeing software failures impact society, yet incidents seem to all be classified as one-offs without society looking at the broader picture and longer terms implications across the board. A recent example of a software failure shutdown a major Sydney motorway for hours during the peak morning period causing much of the traffic in the south of the city to grind to a halt. But, no one asked the question, do we have other such risks in software used in other critical infrastructure? Is society in general still so ignorant of the potential damage to it by software failures? What is going to be a driver for change in your opinion outside of a major catastrophe?

DR: Yes. People are generally ignorant of the potential damage of poorly written software and may not recognize it in the broader context. On a radio interview I gave here in the United States, the first question from the host was “What’s the difference between hardware and software?” I thought, “wow, we have a long way to go from this question to how software vulnerabilities impact daily life.” We got there (eventually), but what struck me is that there are still multitudes of people to whom technology, specifically software, is a complete mystery. They are still baffled as to how to get their printers to work (another question in the interview). Insecure software?!? What’s that?!? To ask them to understand how vulnerabilities on their home computer might impact them is challenging enough, let alone the broader context of software in municipal or critical infrastructure.

In that context them, I see two significant drivers outside of a major catastrophe. First, is awareness. Second, the financial exhaustion that comes from overspending with few meaningful or permanent results.

Just as campaigns against smoking, drunk driving, and drug use was necessary to change the behavior and purchasing habits of millions of people, the same will most likely be true of insecure software. “Bad” software can kill and harm you or your business. People need to be told the story of insecure software in terms they can understand, not in the language of technologists. News coverage is increasing public awareness, but nearly enough. Eventually, the House Committee on Emerging Threats here in the U.S. might even hold public hearings on the issue. That would be a positive step.

So awareness will be a key driver, no matter how insurmountable a hurdle it might seem now. Until the publication of Ralph Nader’s “Unsafe at Any Speed” the populace literally did not understand to what extent they were affected by manufacturing defects in automobiles. Think about that. Something they used everyday and it was not obvious the danger they were in. That book started an uprising that never faltered. I can only hope the same for Geekonomics.

The second driver is more palpable: spending. Organizations are spending ridiculous sums on security technologies. Some will succeed in “securing” their environment (temporarily), but most will not; not enough to make a difference for the rest of us, at least. The private and social costs will eventually become apparent. The private cost of mitigating the affects of insecure software will be so high, that many will short change the process even more so than we see now…which means even less security for those who can technically afford it. The social cost of so much insecure software might come to the point where governments may have no choice but to recognize the social impact of insecure software and may need externally influence the market.

This was the case in 1960s America regarding unsafe cars. The social costs of vehicle defects in terms of lost productivity due to dead or injured drivers (think “workers” here) was estimated to be something like 3 to 4 percent of GDP. Some estimates put it as high as 5 percent, but I was not able to confirm primary sources enough to quote it in the book. Even at 3 percent GDP, this is an enormous amount even by today’s standards.  With those numbers, government could not afford *not* to act. The U.S. needed to spend on tangible, sustainable goals in order to save both lives and productivity. The U.S. was literally bleeding to death.

Putting this into the context of insecure software, even at $100 billion per year, which is the (low) estimated cost of software defects to the United States, this amount represents just under 1 percent U.S. GDP in 2007 dollars. The U.S. is starting to bleed to death once again not in terms of worker’s blood this time, but in intellectual property and finances. If the auto industry is any measure to what the country is willing to bear in terms of social costs then we have a very, very long way to go till we get to 3 percent GDP with possibly hundreds of billions more to lose in all sorts of unimaginable ways before the social cost of insecure software is felt, let alone, recognized.

Of course, catastrophes have a way of speeding the whole process up.

BorB: The almost zero liability that sits with software vendors at present doesn’t encourage change on their part to develop better software. You talk about potential legal avenues in your book that could be pursued and may sometime down the track be used to assist with change. How about targeting false and misleading advertising as another avenue to drive change and allow the consumer to dispute the validity of the software agreement and thus throwing some liability back at the developer? (eg; many developers of “security” software make extraordinary claims about their products that we all know are false and misleading. I believe they’ve never, at least in Australia gotten into trouble because no one has reported them).
Eg; the old classic in Beast of Buddha; “The Symantec Guarantee”:  http://beastorbuddha.com/2008/02/27/symantec-will-save-us-allproactive-protection-against-unknown-and-zero-day-threats/

DR: Like most things in the software world, pursuing legal action around false or misleading claims is a difficult path to navigate. To bring suit against a software manufacturer for common law fraud or for violations of anti-fraud provisions within consumer protection laws requires the consumer (the plaintiff) to establish that the manufacturer (the defendant):

1.    Made a false statement about a material fact.
2.    Intended the consumer to rely on that fact, and
3.    The consumer relied on that statement to their detriment.

It might sound fairly easy to do this, especially with some of the more outrageous statements made by security vendors and/or software manufacturers over the years, but it is not. It is the first and second elements that present the highest hurdles.

If the manufacturer clearly knew the software would not perform as described, and misrepresented that fact to the consumer, the manufacturer could be liable for resulting damages (such as when your database is described as “unbreakable” but then it turns out it is, you get hacked because of it, and lose 30 percent of your customers).

But it is establishing clearly that the manufacturer knew such statements to be false and intended the buyer to rely on that fact that is challenging to prove. Surely, with so much buggy software out there, no rational, intelligent, clear-minded software developer would think their software to be “unbreakable” or some such nonsense. Such a statement must be false because how could the developer ever think that statement to be true?

But there is a difference between being wrong and knowingly making false statements (fraud), however. Manufacturers are liable for fraud; they are not liable for being wrong.

This goes back to a statement I’ve made many times regarding software manufactures. Software manufacturers are not trying to make “bad” software (and thus defraud people by selling it as “good” software); they just do not have an incentive to make better software. Software manufacturers are allowed to be wrong about how secure their software might actually be.

In other words, developers do not think they are making fraudulent statements about their software or its capabilities no matter how wrong they might be…they truly believe their software rocks, even with substantial evidence to the contrary. So software can remain “bad,” with little motivation to make it better.

In the end, and this is important, establishing that statements made by a manufacturer were knowingly fraudulent – rather than wildly delusional – is difficult indeed.

What must be overcome here are those pesky licensing agreements where the buyer agrees to absolve the seller of any and all warranties. In the end, these agreements allow a manufacturer to make any claim or assertion they want. Manufacturers bear no legal or financial accountability to consumers for being wrong and so can make any statement they please, true or not.

Currently, according to my legal sources in Australia, software manufacturers in Australia are aggressively settling law suits brought against them for damages related to software defects. Manufacturers settle cases to avoid having precedent set on the books. Otherwise, the courts decision would become law, and all software manufacturers would fall under its rule. Read it like this: the manufacturers are teaming up against the Australian consumer to protect their interests, not yours.

In the end, it is less expensive for software manufacturers to pay out a settlement for being wrong than to actually do what their customers need them to do. This is similar to the initial tactics of tobacco companies in the United States. (Note, individual States had to eventually bring suit against Big Tobacco because no single group of consumers was influential enough or had enough resources to engage in an extended legal battle). We do not see the same trend of aggressive settlement here in the United States…yet.

So remember, fraud on the part of a manufacturer is against the law. Being delusional is not.

BorB: What are your thoughts on industry consortiums such as SAFECode and the recently announced ICASI, (Industry Consortium for Advancement of Security on the Internet)? Cynics among us would say they are load of marketing and public relations BS to give a perception to us that they are actively doing something.

DR: I’m skeptical, but hopeful. The most cynical of us can state that “it’s all for show.” Frankly, it probably is. Consortia members can huff, puff, and groan and make a wonderful show of effort (if white papers and PDFs are a measure of effort), but until manufacturers are truly held to account, financially and legally, for failing to protect consumers from highly foreseeable malicious activities enabled by preventable software flaws, it will be just that: a show.

In many respects, the industry players are the best ones to develop “solutions” for the problems they have created. In this regard, I am hopeful. Again, the auto market is a good example. General Motors, after finally forgoing all the harassment of public safety advocates like Ralph Nader and conducting legal actions against the U.S. government for imposing “unfair” regulations, decided to lead the way to making a better crash test dummy as well as helping standardize safety standards among auto manufacturers. General Motors actually lead the way, if reluctantly at first.

These manufacturers – auto, software, or otherwise – can be tremendously innovative regarding needs (even when forced). What is decidedly different for the current crop of software industry consortia is that software manufacturers are getting together but without any truly meaningful external stimulus to change their behavior as had auto manufacturers. It’s “best effort,” “good will” and all that for software manufacturers, but with very few repercussions for inaction, or even failure. Consumers still purchase software products in droves despite numerous and continuing vulnerabilities. This is hardly incentive for manufacturers to alter current behavior.

BorB: I’m going to raise the word “regulation” - dirty to some, seen as the solution by others. I’ve seen it work in business in a lot of ways, but what are the obstacles to it being something to enforce better software being released into the market?

DR: Before answering, let me state that I am a devout capitalist with a capital “P” (for profit). I dislike regulation for the same reason that hockey fans hate when the referee breaks up a good fist fight (I’m not sure if Australian football fans feel the same way, but I can imagine a good fight on the pitch is worth a look). Sure the fight is fun to watch, and the refs simply get in the way, but eventually you just want to get on watching the game. Regulation is like that; it provides structure for the playing field that otherwise would not automatically appear…the players are too much in a froth to care about the spectators.

So, I see at least two obstacles to regulation: people and technology.

The first obstacle to overcome then is the notion people tend to have that all regulation is bad. It is not. Bad regulation is bad; that is, misguided, inefficient, and heavy handed regulation run by bureaucrats for their own benefit. Such regulation is bad and should be shunned, mocked, or both. But good regulation can make markets sing because it provides confidences and structure that would not otherwise appear.

In reality, much of regulation in the Western world works, and works quite well. From the food we eat, to the medicines we take, to the products we buy, they are to one degree or another regulated (except software, of course). Is it perfect? Of course not. Regulation does not need to be perfect or pervasive in order to be relevant. But many of us tend to be skeptical of regulation because we tend to focus on instances of profound silliness and idiocy. These moments tend to be surface blemishes, sometimes deep, but oftentimes shallow, that in the end inconvenience but do not cripple.

Efficient regulation provides, through an external stimulus, what a market is not compelled to provide itself: what we need. An axiom of economics is that markets are good at giving us what we want, not necessarily what we need. Where markets fail to recognize the social cost of certain behaviors, regulation provides the necessary incentives to compel companies to recognize “the needs” of consumers – which they themselves might not always recognize – in addition to “the wants” of consumers.

In this context, regulation tends to focus innovation rather than merely quash it. It sets ground rules, as it were, to say what is possible and what is not. In the software market, the light of innovation is bright, but is also tends to be unfocused…meaning that you can do anything with software that you like, except perhaps make it secure.

Which leads us to the second obstacle for regulation: technology. More accurately, the technical aspects of putting a regulatory regime in place. How do we judge the assurance level of software and enforce it? How do we actually hold manufacturers to account? These questions deserve books of their own, but here are some thoughts.

The Department of Homeland Defense publishes CAPEC, Common Attack Pattern Enumeration and Classification. The attack patterns, that is, the common ways people exploit software, have not changed that much in 40 years. Heck, buffer overflows (simple input validation, really) remain a significant issue and has been a significant issue for as long as we can remember. We know what attackers are looking for, but software manufacturers do not have the incentives to squeeze out these flaws in sufficient quantities before releasing products.

One method then, is to “crash test” software against these known attack patterns much the way automobiles are crash tested against common crashes (head-on, side impact, etc) and then assign a rating based on the software’s performance.

Now of course, software exhibits many more variables in how it can be attacked and this testing will not be perfect or complete. And manufacturers will whine incessantly about time to market (which doesn’t seem to be a problem for other industries that affect human lives and interests, by the way).  But what this method does do is make the security of an application visible just as the safety rating on a car makes safety visible. A ratings perfect? No, but without ratings buyers are in the dark. A rating allows consumers to choose the bucket of risk they are willing to purchase into.

On to the enforcement part. Immediately critics tend to jump to the conclusion that government will get neck deep into telling manufacturers how to make software and they’ll mess the whole thing up. I believe this observation is accurate. Government, if involved in the manufacturing of software, cars, or anything else for that matter *will* tend to mess things up. But that is not the way efficient regulation works.

For example, the U.S. NHTSA safety rating for vehicles allows the market to choose, and therefore, enforce, the level of safety car buyers are willing to accept. In the United States, nearly 90 percent of vehicles are four or five star rated. People want safe cars, and buy accordingly. More importantly, manufacturers respond to this “need” because buyers can demonstrate this “need” in their purchasing habits. The safety rating system has made this much obvious. But it’s more than that.

In essence, the five star rating system imposes an “unsafe tax” on auto manufacturers. It is an enforcement mechanism. Manufacturers insisting on producing less-than four-star rated cars are punished by buyers; that is, buyers do not purchase their vehicles. The safety rating system is actually a cleverly disguised punitive tax enforced by buyers, not government. Manufacturers that make one-star rated cars forgo all revenues they could have obtained by making a four- or five-star rated car. That is a very expensive tax indeed, one that manufacturers avoid paying with all their might.

So what I just described is the ideal, even if it isn’t perfect. The government sets the boundaries, but the market enforces. NHTSA assigns the rating system and the spectrum for testing vehicle safety. Importantly, government does not tell the manufacturers how to do their job (for the most part). It is up to the manufacturers to determine the most efficient and effective way of meeting consumer needs in addition to satisfying consumer wants. So it could be the same in the software market.

There are many more obstacles than listed above, of course. The technical details, nuances, and nits are bewildering, but it is something I believe can be done. In the end, it remains immensely ironic to me that an industry known for innovation insists that the technical hurdles are not something they can innovate around. It is. If only they have the incentive.

BorB: Putting you on the spot here: knowing what you know and seeing where things stand at present, where do you realistically see things in 2-3 years time?

DR: As the saying goes, “never make predictions, especially about the future.” But here’s a go at it.

I see me in South Africa, 2010 World Cup.

BorB: Is there a plan for a follow-up book or revisions in the future (given how quickly things in the IT industry move)?

DR: Yes, a new book. I’m researching the economics of cyber crime particularly the underground vulnerability market. I touched on this topic only lightly in Geekonomics, but the more I uncover, the less I am able to sleep at night.

BorB: Any final thoughts or messages you’d like to leave us with?

DR: We can do this. We can make a better cyber environment. Software defines this environment and it must be suitable to the task. It will be difficult, challenging, and frustrating. But we can do it.  The battle over insecure software is not necessarily between buyers and manufacturers, but between society and malcontents. Insecure software enables highly foreseeable malicious activities. Stop giving the malcontents the raw materials to attack us with: stop handing them new vulnerabilities. Reduce their supply. It should be harder for hackers to discover vulnerabilities than it is for us to defend against myriads of them. We can do this.