David Rice
David Rice
Safari: What motivated you to write a book about the real costs of insecure software?
Rice: I wanted to make the issues surrounding insecure software approachable by "regular" people, not just technology experts, gurus, and specialists. Software touches all of our lives, yet very few of us understand it or the issues surrounding it.
Software is amazing, that much is clear. Software can and does make our lives easier and better as do many other technological advances. But this is not the entire picture. Everything has a cost. Nuclear technologies have a cost, recycling has a cost, organic produce has a cost. Some costs are more evident than others. In the end, the real cost of something is not what we pay, but what we give up in order to get it.
Safari: What are giving up when we buy insecure software?
Rice: As it turns out, a lot. The financial impact of insecure software is stunning to be sure, but it is becoming quite clear to a number of organizations and national agencies that what we are giving up is economic and national security. Less obvious but no less important is that we are also giving up to some extent future economic progress. The money we spend on protecting software is money that cannot be spent on other things. So why do we still purchase insecure software and why is the market still flooded with it? In part, that is what Geekonomics attempts to answer. It has to do with incentives.
Safari: Yes, I noticed that incentives, rather than technical solutions, is a big theme in your book. Why?
The story of insecure software is just as much an economic issue as it is a technology issue. There are plenty of process and technology solutions in the market to improve software, but these solutions are used inconsitenty, incompletely, or not at all by software manufacturers. This is baffling until we look at the situation through the lens of economics.
To me, a compelling aspect of economics is that economists tend to stubbornly maintain the fiction that people are rational, even when much of human behavior appears exactly the opposite. Instead of selectively attributing bizarre conundrums of human behavior solely to human irrationality, economists tend to focus on finding rational explanations for our behavior. Economists look for incentives because incentives matter in human endeavors. Explanations for our behavior might appear peculiar at first, even outlandish, but as the maxim goes: sometimes truth is stranger than fiction. This is in part what Geekonomics attempts to do: identify the incentives driving people make, buy, and exploit insecure software (and tell a good story while doing it).
In the end, the story of software is the story of us, and that is a very interesting story indeed.
Safari: Who did you write this book for? Executives and managers, programmers, system administrators, politicians and other people not even working in the technology sector? All of the above?
Rice: Yes, absolutely. Geekonomics is a "big picture" book intended to inform as well as entertain. At base, Geekonomics is about good public policy, so Geekonomics is intended for "the public."
I wrote Geekonomics with the intention of providing an understandable, comprehensible story about software and how it intertwines with and impacts our modern lives. Geekonomics is not necessarily intended for my professional colleagues, or even technologists, though I hope they enjoy reading it. Geekonomics is intended for everyday readers who like an illuminating story.
Safari: In Geekonomics: The Real Cost of Insecure Software you write that the software industry is rewarded for carelessness. How does this happen?
Rice: Great question. LetÕs assume, for the sake of argument, an auto manufacturer builds a car in 2006. When tested for safety, the car is given a one-star safety rating. Assuming a very stubborn manufacturer, what will most likely happen when the auto manufacturer places that vehicle into the market place when 90 percent of all other cars have been given a safety rating of four or five stars?
Most likely, the one-star car will not sell very well. In essence the market "punishes" the auto manufacturer for making an unsafe car; that is, buyers will be strongly reluctant to purchase a one-star rated car, if at all. Because of government safety regulations, buyers know whether the car they intend to purchase is safe or not. This knowledge matters at the point of sale.
Given this external influence on the market, the auto-manufacturer is not rewarded for carelessness (for failing to pay attention to public issues), but is punished by the market via lower sales for one-star rated cars. If the auto manufacturer chooses to make more unsafe cars and forgoes making safer cars, the manufacturer is punished to the point of being pushed from the market entirely. In order to avoid this "unsafe tax" imposed by government regulations (and enforced by the market), manufacturers strive to make better, safer cars.
The story of software is completely different than the one above. Software manufacturers are permitted to place a product in to the global stream of commerce without any statement or objective measurement of its "safety" or "security." Just as the auto market was entirely subjective in the 1950s and 1960s, so too is the modern software industry. This means the market does not have a suitable mechanism to punish software manufacturers that choose to build lower-quality, less-safe, less-secure software. So what happens?
None of those aspects are included in the product (or if they are, to arbitrary and subjective levels) thus making it quite lucrative for the manufacturer to place a product in to the global stream of commerce that endangers people, money, and treasure. Software manufactures are rewarded for carelessness; that is, for not paying attention (or enough attention) to aspects of manufacturing that affect the public good.
In economic terms, the private cost (what the manufacturer pays) of making insecure software is too low compared to the social cost (what everyone else pays because of their behavior). Because software manufacturers do not pay the social costs of insecure software, there is no compelling incentive for manufacturers to make better, more secure software.
Now, an immediate counterargument is that the auto manufacturer analogy fails to sufficiently distinguish between safety and security when applied to the software world. Cars are made safer by improved manufacturing techniques to be sure, but these techniques do little in terms of security should a hooligan smash the windshield or vandalize the car in some way. This counterargument sounds entirely reasonable. But this is not the case in the story of software.
Attackers do not arbitrarily exploit software as hooligans arbitrarily smash windshields in the physical world. In the software world, there is a tight relationship between software vulnerabilities and software exploits. For instance, exploit code such as Code Red does not work against a Linux machine. Why not? Because there is no corresponding weaknesses in the Linux software that allows it to be exploited by Code Red.
In essence, Linux is immune and impervious to Code Red because Code Red does not exploit a Linux manufacturing defect. In order to exploit a Linux vulnerability, an attacker must find a defect in the Linux software that the Linux community failed to discover themselves. Similarly, if the Microsoft web server did not have that particular vulnerability (e.g. Microsoft avoided the defect in the first place), Code Red would not have been built. There is a tight relationship between a software exploit and the vulnerability in the software it exploits.
Let me put it this way, in the absence of a software weakness (a vulnerability) an attacker cannot exploit the software directly. This is, of course, why the security community tells people to religiously patch their systems. Remove the defect and the impact of the exploit goes away. In other words, in the story of software, the hooligan is not necessary to shatter the windshield of the car. A vulnerability is simply an invitation to exploitation; the attacker does not need to break the windshield himself. The manufacturer did that for you.
In light of this, construction quality in software matters greatly. In the absence of a defect, exploiting software directly is difficult indeed, if not impossible. Exploits for Microsoft vulnerabilities simply do not work against Linux vulnerabilities and vice versa. A hooligan cannot arbitrarily shatter a windshield or otherwise vandalize a car in the story of software. The hooligan needs an invitation, an openingÉand the manufacturer provides that. Of course, this explanation does not address the larger issues of information security (such as users sharing their passwords), but merely software assurance.
In short, the market rewards software manufacturers for making low-quality software. It is less expensive to make lower quality, insecure software than it is to make higher quality, secure software. Compared to the auto market, the software market is completely inverted.
Safari: How does the shift from software designed to run on a single computer to web-based software services impact the security issues you've examined?
Rice: The move to software as a service is not nearly as compelling as promised, either from an economic perspective or a security perspective. In fact, both issues are tightly intertwined.
From an economic perspective, vendors of commercial software that make software for a single computer make an absolute financial killing on customers through high licensing and maintenance fees. This, of course, is not wasted on software buyers who look to the software-as-a-service (SaaS) model to save substantial amounts of money. But high fees on the part of the software manufacturer in essence subsidized not only new software projects for the manufacturer, but the money necessary to repair defects in previous software projects. Repairs, mind you, the manufacturer had little-to-no incentive to make before the product shipped in the first place. Why do so when the customer can be made to pay more for a relentless stream of fixes and patches?
In an odd way, these high fees are compelling for the manufacturer to be sure, but almost as compelling for the buyers. How else would the buyer's software get repaired? Paying licensing and maintenance fees are a continued investment in ensuring the business' IT infrastructure does not fall flat on its face, and with it, the company.
In comparison, the software as a service model has to make due with subscription fees, which in general, tend to be less than licensing and maintenance fees of its multi-instance cousins. Lower fees are compelling to software buyers, but it can have a downside. Lower fees means the software manufacturer is making less than their multi-instance cousins. This means less money to invest in software production and/or repair defects in software. Of course, since the software service is used primarily through Internet browsers and does not need to run directly on arbitrary platforms, production costs tend to be less for SaaS. This can also mean that repair costs might also be lower. In this regard, the software service model can "work," but sustainability is uncertain. As of 2007, NetSuite has never made a profit, and Salesforce.com has only done slightly better despite being ten years older.
The issue of sustainability is not particularly enlightening by itself. Where sustainability is especially poignant for SaaS however, regards security. Features sell. Period. Under the SaaS model, software manufacturers add features incrementally and on-demand to satisfy client requests as well as remain competitive. This sounds like a good thing to both buyers and manufacturers. It is not, at least not under the current market circumstances.
The market incentive for software manufacturers is to add as many features as possible because features are part of the beauty contest among software applications. Features are also inexpensive to add. Security is not. This means SaaS applications are guaranteed to have a continuous and relentless stream of ad-hoc features (over and above the rate at which features are added by multi-instance cousins) each of which add more complexity to the application and the likelihood that one or more of those features contains a bug (at best) or a vulnerability (at worst).
With less money available through subscription fees, it is reasonable to argue that SaaS companies might be even more selective (or more argumentative) in fixing or admitting to software defects. Fixing software costs money. Without additional maintenance fees, and a relentless stream of new features added continually, where will this money come from? Perhaps from higher subscription fees, but doing so works against the SaaS company in competing for IT dollars. So the incentive is to add more features, but not necessarily fix them.
Looking to SaaS to solve the problems and expenses of software is short sighted. Security and quality concerns will most likely intensify under the SaaS model, or just be dressed up in different ways so they are not easily recognized. The engineering techniques of SaaS are not that much different than engineering techniques of multi-instance vendors. Further consider the downward pressure on fees, and there might be even less motivation to address old (and common) engineering problems.
Safari: What are the most important steps that can and should be taken to improve the security of software today? How can we get software companies to focus less on a product's feature list and more on its underlying stability and security?
Rice: Change the incentives of software manufacturers. To reiterate my earlier comment, the market rewards companies for making low-quality software. It is less expensive to make lower quality, insecure software than it is to make higher quality, secure software. Compared to the auto market, the software market is completely inverted.
In the presence of robust safety regulations, it is far more expensive for an auto manufacturer to make an unsafe car because most market participants will refuse to purchase such a car. The "safety" of the car is made visible through the NHTSA five-star system and quality is made visible in part through consumer reports.
While the production cost of a building a high-quality, safer car is inarguably higher than building a low quality, less safe car, what the manufacturer might save in producing a "bad" car is completely nullified when the car goes to market. The unsafe car must compete against other cars that are safer. In other words, auto manufacturers must forgo greater revenues in order to make an unsafe car. This makes building an unsafe car very, very expensive.
The same or similar model is needed for software. While the production costs of high-quality, secure software will be inarguably higher than building low-quality, feature-rich software, what the software manufacturer might save in producing "bad" software must be completely lost when the software goes to market. High-quality products tend to drive lower quality products from the market; that is, when the differences between the two are made visible to market participants.
Safari: One of the premises of your book is the concept that software is becoming the foundation of our modern civilization: "Software constitutes or will control the products, services, and infrastructure people will rely on for a wide variety of daily activities from the vital to the trivial." How can we as a society improve the stability, reliability, and security of this important new type of infrastructure, when most of us aren't involved in creating software?
Rice: Ah, but all of us are involved in creating software. Not in the act of manufacturing software, of course, but in determining what gets manufactured. Markets are powerful forces. They give us what we want, not necessarily what we need.
Markets are also plagued by asymmetry of information; that is, one party in the transaction (typically the seller) knows more about a product than the other (the buyer). As buyers, we might never enjoy perfect information about a product, but we can have enough information to make a reasoned purchase. The NHTSA five-star rating is one simple way of transmitting information to the buyer about the safety of a vehicle without expecting the buyer to become an expert of vehicular safety design.
To be frank, software is magic to many people. This is OK. Some of us like magicians because the asymmetry of information is so stark. We have no clue as to how the magician pulled off his trick. ThatÕs fine for a show, but not for infrastructure, not for products that directly impact the health, safety, and welfare of the public as does software.
One of the problems with software is that the quality and security of software remains largely opaque to buyers. Buyers are unable to gather enough information to make a reasoned purchase and therefore are unable to sufficiently distinguish between high-quality and low-quality software. As a matter of good public policy, we need to give buyers this option. What the options might eventually look like is still open to debate (as it should be).
Safari: Do you see a greater role for governments in improving and securing this software infrastructure?
Rice: Yes, to a limited extent. I am not a big fan of invasive government involvement in the software market. An external stimulus on the software market needs to be balanced. Software is immensely complex and the argument that government might retard the software market has some merit. Government cannot always be trusted. Nor sadly, can some software manufacturers.
That said, despite heavy regulation in the auto market, Nissan and Toyota remain wonderfully innovative. In fact, regulation has helped Nissan and Toyota focus their innovative capabilities. The same might be true for software.
The obvious advantage of software is that you can do anything with it that you want. It is also just so happens that this property is exactly what makes software so difficult to constrain. No one wants to give up the ability to innovate, especially in the software world. Regulation (or whatever oversight we might agree on) restricts innovation to be sure, but it also pressures and focuses innovation.
Nissan and Toyota have complained very little about U.S. DOT regulations (at least not like U.S. auto makers have). In fact, Toyota and Nissan are incredibly innovative despite regulation. This is in part because Nissan and Toyota are free to innovate on fewer things, making those innovations better. Their energy is focused. In software, the light of innovation is bright, so to speak, but unfocused. You can do anything with software, and that is exactly the problem.
Building standards/regulations for just about anything can (but not always) make production more efficient. What the market might lose in restriction it gains almost exactly that much in efficiency. In other words, instead of a manufacturer potentially having options A, B, C, D, E, and F in manufacturing an output, the manufacturer now only has to worry about doing A, B, E, and F. The options for buyers are fewer, yes, but that means the manufacturer can optimize the production and quality of those specific options. The market is allowed to build anything it wants within limits. The market is constrained Š not crushed Š just responsibly constrained.
Safari: So there's a trade off between safety, security, and innovation?
Rice: You bet. There is a maxim that goes something like this, "All architecture is based on trade-offs." And that is why Geekonomics is in part a public policy book. What aspects of software will we tolerate, and which will we not? The low-water mark, so to speak, can perhaps be most effectively set by government. However, the market is best at enforcing the rest.
Safari: Tell us a little bit about some of the global implications of insecure software. In Geekonomics you go beyond just talking about the security of our PCs and get into the security of our nations and lives. What are some worst-case scenarios for adopting poorly written software for crucial infrastructure tasks?
Rice: There are security implications to be sure. Software vulnerabilities are invitations to exploitation. The problem of one is the problem for all in the networked world. Estonia is now very sensitive regarding its cyber security after the onslaught of Russian hackers emoloying hijacked PCs from around the world to attack their infrastructure. Cyber espionage and even cyber warfare are brutal realities of the Information Age. At this time, geographic boundaries mean very little as does the jurisdictional reach of law enforcement. The Central Intelligence Agency recently confirmed that cyber attacks have been employed against U.S. utilities causing power outages that affected multiple cities. This augurs ill. But the costs associated with cyber attacks are only a small part of the picture. In fact, the worse-case scenario in the story of insecure software has nothing to do with security at all, but our economic future.
Insecure software, and indeed the security products we use to protect software from exploitation, hurt our economic progress. Not only does it hurt the economic progress of the United States, but the rest of the world as well.
By way of explanation, let me share a short story.
One day in a small village, a teenager throws a rock through the window of a local bakery and runs off before anyone can catch him. The shop keeper comes storming out, furious at the vandalism. His yelling attracts the attention of his fellow villagers, who at first are as displeased as the shop keeper at the event. After everyone has calmed down a bit, the more optimistic among the villagers remind everyone that this event, in a way, has an upside. If it were not for broken windows, the glass maker in the local village would not be necessary. After all, if broken windows never occurred, who would remain in the glass business? This event makes business for the glass maker. If a new windows costs $100, the baker must pay the glass maker exactly that amount to get the window fixed. This in turn means the glass maker has $100 to spend on other items with other merchants, thus those merchants have money to spend on yet more items with yet more merchants, and so on and so on. In fact, the broken window has a cascading effect that benefits the whole village. While the crowd remains largely displeased over the teenager's actions, it may be, the villagers reluctantly conclude, that the teenager has created some good. If this were the villagers reasoning, they might come to see the teenager as a benefactor, as opposed to a public nuisance.
Simplistic? Yes, but this story has a point. Economists like stories such as this because what a story may lack in complicated detail, the story more than makes up for in illumination.
The reasoning of the villagers in this story is the same erroneous reasoning applied to natural disasters such as Hurricane Andrew. In essence, this line of reasoning concludes that disaster actually benefits the economy. Disaster is not necessarily understood as a nuisance. The more optimistic among the population try to look for some good out of the event and conclude that the extra spending because of the disaster actually benefits somebody and is thus good for the economy.
The massive destruction of Hurricane Andrew meant thousands upon thousands of homes needed to be repaired or rebuilt, subsequently creating work for thousands of people and new invoices for thousands of replacement refrigerators, cars, windows, roofs, and so on. The additional purchasing and employment is thought to ultimately help the economy. Yet, like the village story above, this simply is not true. LetÕs find out why.
The reasoning about the broken window in the village, or the massive destruction caused by Hurricane Andrew, is correct insofar that the event did in fact create more business. In the case of the village, the glass maker needed to make another window for which the baker was required to pay him. In the case of Andrew, builders needed to build or repair homes for which home owners were required to pay them. This much is obvious. What is less obvious is that victims in both cases will be out the money (either in direct payments or insurance premiums) they intended to spend on something else. This is bad.
In the case of the baker, he will be out $100 that perhaps he was hoping to spend on something else, such as a new suit. Instead of having an unbroken window and a new suit, the baker will now have a fixed window and no suit. Because the baker is a member of the village, the village has now lost a new suit that it would otherwise have, and therefore the village is just that much poorer.
What has happened here is not so much that the baker has paid the glass maker, but the baker has not paid the tailor. The tailor, having no demand to make suits, does not make any. Something of additional value that could have been created is not. An opportunity is lost. Demand is foreclosed and need takes it place.
The suit the baker could have purchased he now cannot because $100 has gone to fix the broken window. In short, the glass maker's gain of business is simply the tailor's loss of business. Though a broken window has been fixed, no new benefit has been added to the village as a whole because the broken window has precluded the new suit.
If broken windows became common enough in the village, demand for new suits, or new washing machines, or new TVs would never arise. And the village would be just that much poorer.
The villagers, like the news media in the case of Hurricane Andrew, only see two parties in the transaction of the broken window, when in fact there are many more. The villagers only see the baker and the glass maker. The news media only sees home owners and builders. The villagers do not see the tailor because the tailor will now not enter the picture. The tailor is forgotten from the equation precisely because there will now be no demand for something he makes. The tailor is invisible but no less real.
As the message of Geekonomics attempts to convey, the real cost of something is not what we pay, but what we have to give up in order to get it. In the case of the baker, he had to give up a new suit to fix his window. He lost $100 as well as his new suit. As a result, the village is worse off. The victims of Hurricane Andrew are in the same position. Victims of Andrew are spending to reclaim what was lost, not purchasing new items in addition to what was already possessed. Victims now have a fixed house and no new suit, so to speak. In other words, the victims of Andrew were spending extravagantly just to run in place, not to create demand for new items of value. The "village" is worse off because of it.
Against this background, then, is the story of insecure software and the security products we purchase to protect insecure software from exploitation. As Geekonomics argues, software vulnerabilities are the broken windows of cyberspace. Vulnerabilities communicate an unmistakable message of disorder in global digital neighborhood. This disorder imposes a significant cost in terms of cyber crime and cyber espionage; yet, this cost is only the tip of the iceberg.
Unlike the young teenager in the village story, cyber attackers do not break windows; attackers discover windows broken by the manufacturer. Once discovered, cyber attackers then use the defect to exploit the software and all information it protects. In other words, cyber attackers do not throw rocks and thus create broken windows. Broken windows come with the product compliments of the manufacturer.
Nonetheless, broken windows (software vulnerabilities) must be fixed, just like the baker must fix his broken window if he is to send a message of care and attention about his shop. Who likes to visit a run down bakery or any disheveled food establishment? But because a broken window must be fixed, something else must be given up to fix it.
Insecure software must be patched (or better yet, never produced in the first place). While the patch might be free, the process of patching is not. The greater the number of computers under your control, the more difficult it becomes to keep everything patched. Patching becomes quite expensive.
But insecure software must not only be religiously patched, but protected from exploitation because new, unknown vulnerabilities are discovered every day for which no patches might yet exist. In fact, software is full of latent defects. You, nor the manufacturer, have any idea about how many broken windows a given piece of software actually contains. Therefore, software must not only be patched, it must also be protected with a fantastical panoply of security products like intrusion detection, firewalls, anti-virus, and so on.
The $65 spent on a single instance of anti-virus, the $3000 spent on a network firewall, or the $254 per machine spent on patching software, means exactly that amount of money cannot be spent on something else. Software buyers, like survivors of Hurricane Andrew, or the village baker, are spending just to run in place. This is bad. And not entirely accurate.
In reality, software buyers are not running in place. Software manufactures release a relentless stream of software defects into the global stream of commerce. Cyber crime and cyber espionage are increasing at astounding rates despite massive expenditures to forestall the increase. Software buyers are spending frantically only to lose ground. This is not only bad, this is disastrous.
When software buyers purchase insecure software and security products to protect insecure software from exploitation, other things of value will not be created because buyers no longer have the extra money to purchase them. Instead of having high-quality, secure software and a new suit, software buyers now have patched or protected software and no new suit, no TV, no DVD player, no new car, and so on. This makes the "global village" just that much poorer. Insecure software, and the security architectures we use to protect it, is far more expensive than we can ever imagine.
Just ask the tailor.
Safari: You seem to have struck a real nerve with Geekonomics, it's getting lots of attention and rave reviews. Clearly the costs and dangers of poorly written software are issues that matter to many and can affect us all, but for some reason this isn't a topic that is commonly discussed. Why do you think these issues have been swept under the rug for so long?
Rice: A number of reasons. First, software is a ghost in the machine. It is not visible or visualizable. Nor are software's properties. We can't see software like we can see cement, a bridge, or a building. There are few helpful visual cues. If a bridge appears to be crumbling, we hesitate to cross it. In contrast, if software is "crumbling" we have no visual cues to avoid it. As such, there is a tremendous lack of information about software quality and security even for the professionals. For "regular" people, the non-experts, this lack of information is even more extreme and perhaps even more dangerous.
Second, the lack of information for regular people is compounded by the professionals themselves. On the whole, software developers and security professionals are a very bright group. But our detailed discussions and nit picking in our conversations tends to alienate the very people who should be listening. Heck, it even alienates some people within the profession. This is unfortunate.
I heard a comedian once state, "the best way to upset a geek is to get his obsession wrong. Drive by a line of geeks waiting for the next Star Wars convention and yell 'Star Trek sucks!'"
This little joke seems to typify the story of software developers and security professionals. We are professional geeks, and Heaven help the individuals who do not understand the language of our obsession. So we alienate people. Those things that should be made visible to the public, are not. We drive people away who could make a change in the market place. They could vote differently with their dollars if only they knew what was at stake. But they don't. And the problem only gets worse.
Software buyers should not need to become software developers to understand the benefit of secure software any more than auto buyers should be expected to become mechanics to understand the benefit of safe cars. This is a common, but unreasonable expectation in the software world that I believe should be put to rest.
