Customer Reviews

Geekonomics: The Real Cost of Insecure Software

5 star:		(6)
4 star:		(1)
3 star:		(0)
2 star:		(2)
1 star:		(0)

 

 

Every once in a while I encounter someone's work whose sanity of argument, integrity of passion, and elegance of expression convinces me in an instant that I have found a comrade. Recently reading the new book "Geekonomics" by David Rice was such an encounter. Rice is a prophet, and like most true prophets, what he is saying is something you won't like hearing. Geekonomics warns against the dangers of software. That's right--software--which we rely upon every day to a rapidly increasing degree. Rice is no crackpot or self-proclaimed guru looking to make a quick buck with this book. His warnings are akin to those of Alan Cooper in "The Inmates are Running the Asylum" and my own as well. While Cooper and I rail against software's inexcusable dysfunctionality, however, Rice points out very real dangers that threaten the world. Most software is bad, not just because it is much harder to use and far less effective than it ought to be; it is also insecure, which invites danger. The more we rely on software, the more vulnerable we are to the whims of those who would do harm.

Geekonomics explains the fundamental reasons why software of all types usually fails to deliver what we need, especially security, and the threat that this failure invites. The dangers that Rice describes are on the scale of global warming. Did this statement get your attention? Good, because it's true, and the magnitude and imminence of this problem deserves your attention. Just like the threat of global warming, we dare not ignore the threat of insecure software, because software has become the infrastructure of the modern world.

Geekonomics is not only an important book, it is also a good book. Rice is smart and thoughtful, and he knows how to write. If you rely on software (and who doesn't?), you should read this book. If you produce software, you should read this book. You might not like what you read, but you need to hear it, and we all need to do something about it.

First the good news -- in a fascinating and timely new book Geekonomics: The Real Cost of Insecure Software, David Rice clearly and systematically shows how insecure software is a problem of epic proportions, both from an economic and safety perspective. Currently, software buyers have very little protection against insecure software and often the only recourse they have is the replacement cost of the media. For too long, software manufactures have hidden behind a virtual shield that protects them from any sort of liability, accountability or responsibility. Geekonomics attempts to stop them and can be deemed the software equivalent of Unsafe at Any Speed. That tome warned us against driving unsafe automobiles; Geekonomics does the same for insecure software.

Now the bad news -- we live in a society that tolerates 20,000 annual alcohol-related fatalities (40% of total traffic fatalities) and cares more about Brittany Spears' antics than the national diabetes epidemic. Expecting the general public or politicians to somehow get concerned about abstract software concepts such as command injection, path manipulation, race conditions, coding errors, and myriad other software security errors, is somewhat of a pipe dream.

Geekonomics is about the lack of consumer protection in the software market and how this impacts economic and national security. Author Dave Rice considers software consumers to be akin to the proverbial crash test dummy. This combined with how little recourse consumers have for software related errors, and lack of significant financial and legal liability for the vendors, creates a scenario where computer security is failing.

Most books about software security tend to be about actual coding practices. Geekonomics focuses not on the code, but rather how insecurely written software is an infrastructure problem and an economic issue. Geekonomics has 3 main themes. First -- software is becoming the foundation of modern civilization. Second -- software is not sufficiently engineered to fulfill the role of foundation. And third -- economic, legal and regulatory incentives are needed to change the state of insecure software.

The book notes that bad software costs the US roughly $180 billion in 2007 alone (Pete Lindstrom's take on that dollar figure). Not only that, the $180 billion might be on the low-end, and the state of software security is getting worse, not better, according the Software Engineering Institute. Additional research shows that 90% of security threats exploit known flaws in software, yet the software manufacturers remain immune to almost all of the consequences in their poorly written software. Society tolerates 90% failure rates in software due to their unawareness of the problem. Also, huge amount of software problems entice attackers who attempt to take advantage of those vulnerabilities.

The books 7 chapters are systematically written and provide a compelling case for the need for security software. The book tells of how Joseph Bazalgette, chief engineer of the city of London used formal engineering practices in the mid-1800's to deal with the city's growing sewage problem. Cement was a crucial part of the project, and the book likens the development of secure software to that of cement, that can without decades of use and abuse.

One reason software has significant security vulnerabilities as noted in chapter 2, is that software manufacturers are primarily focused on features, since each additional feature (whether they have real benefit or not) offers a compelling value proposition to the buyer. But on the other side, a lack of software security functionality and controls imposes social costs on the rest of the populace.

Chapter 4 gets into the issues of oversight, standards, licensing and regulations. Other industries have lived under the watchful eyes of regulators (FAA, FDA, SEC, et al) for decades. But software is written removed from oversight by unlicensed programmers. Regulations exist primarily to guard the health, safety and welfare of the populace, in addition to the environment. Yet oversight amongst software programmers is almost nil and this lack of oversight and immunity breeds irresponsibility. The book notes that software does not have to be perfect, but it must rise to the level of quality expected of something that is the foundation of an infrastructure. And the only way to remove the irresponsibility is to remove the immunity, which lack of regulation has created a vacuum for.

Chapter 5 gets into more detail about the need to impose liability on software manufacturers. The books premise is that increased liability will lead to a decrease in software defects, will reward socially responsible software companies, and will redistribute the costs consumers have traditionally paid for protecting software from exploitation, shifting it back to the software manufacturer, where it belongs.

Since regulations and the like are likely years or decades away, chapter 7 notes that short of litigation, contracts are the best legal option software buyers can use to leverage in address software security problems. Unfortunately, most companies do not use this contractual option to the degree they should which can benefit them.

Overall, Geekonomics is an excellent book that broaches a subject left unchartered for too long. The book though does have its flaws; its analogies to physical security (bridges, cars, highways, etc.) and safety events don't always coalesce with perfect logic. Also, the trite title may diminish the seriousness of the topic. As the book illustrates, insecure software kills people, and I am not sure a corny book title conveys the importance of the topic. But the book does bring to light significant topics about the state of software, from legal liability, licensing of computer programmers, consumers rights, and more, that are imperatives.

It is clear the regulations around the software industry are inevitable and it is doubtful that Congress will do it right, whenever they eventually get around to it. Geekonomics shows the effects that such lack of oversight has caused, and how beneficial it would have been had such oversight been there in the first place.

To someone reading this review, they may get the impression that Geekonomics is a polemic against the software industry. To a degree it is, but the reality is that it is a two-way street. Software is built for people who buy certain features. To date, security has not been one of those top features. Geekonomics notes that software manufacturers have little to no incentive to build security into their products. Post Geekonomics, let's hope that will change.

Geekonomics will create different feelings amongst different readers. The consumer may be angry and frustrated. The software vendors will know that their vacation from security is over. It's finally time for them to get to work on fixing the problem that Geekonomics has so eloquently written about.

Depending on who you ask, mankind has survived on this planet for somewhere between 10,000 and 160,000 years. However, we are the first generation to be dependent on software. Geekonomics opens with a discussion of the importance of cement and how crucial it is to our civilization. From roads to sewers, cement is our infrastructure and I could not agree more. After the driest summer since they have been measuring such things, the rain has been falling and falling and falling and my farm is one big mudhole. Every unimproved road is dangerous and some of the asphalt is failing. So I am replacing and improving with cement. It is expensive, but cement roads will outlast me, my son and his sons. Software is as important to infrastructure as cement as a foundation of civilization asserts the author of Geekonomics, David Rice, but while considerable energy has been expended to normalize the manufacture and application of cement, much less work has been done with software.

While the cement roads we are putting in will last a hundred or more years, the author points out that software is often essentially obsolete by the time the consumer takes possession of it. In fact, consumers value innovation so much, that it is prized above security even if a quick look at the news shows us the cumulative effect of software failure leading to data breach. At this exact moment, according to privacyrights.org, 216,770,536 consumer records have been lost. As Rice points out, in the 1970s the criminal underground realized there was more money to be made, at less risk of being caught, trafficking in drugs than other forms of crime, so it became a big thing. In the past few years, the criminal underground is starting to focus on software, specifically vulnerabilities in software that can lead to data breaches that allow identity theft and credit card fraud.

As the book explains, crime begets crime, if you have a neighborhood with broken windows, this can lead to additional problems, criminals and other worthless fellows are comfortable hanging out and doing whatever they want to do. This too, I have seen in my own life, one of my employees has had to abandon her home for a few weeks. The condominium above her had a broken window that was used to enter that home and people took up residence in the empty foreclosed home. They invited their friends and now the entire complex is less desirable. Geekonomics lists the positive example of the New York Subway system's clean car program, that all cars had to be clean with no graffiti, if a car could not be cleaned it was taken out of service until it was clean. This has lead to a major improvement in the security and user experience of the subway system. However, as the author points out, you can see graffiti, you cannot necessarily see the flaws in software that attract the criminal elements.

Another interesting comparison the book makes is the interstate highway system in the US. It was designed for safety from the beginning and is a critical part of the national infrastructure. If you want to go somewhere you can. For all its costs, having this infrastructure in place saves far more money, imagine trying to get fresh milk to market over muddy, pot hole filled roads. However the Internet, which is the software analog of the highway system was not built for safety and may well not scale to growth as well as the highway system has.
The book continues example after example to show how our legal system does not aid the consumer to receive quality and safety from software, but if fact makes the problem worse. Rice does not simply dwell on problems, after strongly establishing his case, he points the way to the changes that need to take place if we, the first generation to be truly dependent on software are going to prosper. This is an important book, it does not require knowledge of IT or software development to read, every thinking man and woman should read this book and ask, what can I do? Standards, quality and making incentives achieve the results we want and deserve are key. As the author says, "I believe we have not gone too far down the path to alter course, but we aren't trying hard enough yet." That is the call to action, write your legislator, lobby consumer organizations, do what you can, but advocate rational software. Thank you David Rice.

I really, really liked Geekonomics, and I think all security and even technology professionals should read it. Why not give the book five stars then? The reasons are twofold: 1) the book fails to adequately differentiate between safety and security; and 2) the chapter on open source demonstrates fundamental misconceptions that unfortunately detract from the author's message. If you are kind enough to keep the thoughts in this review in mind when reading Geekonomics, you will find the book to be thoughtful and exceptionally helpful.

It is important to remember that Geekonomics is almost exclusively a vulnerability-centric book. Remember that the "risk equation" is usually stated as "risk = vulnerability X threat X impact". While it is silly to assign numbers to these factors, you can see that decreasing vulnerability while keeping threat and impact constant results in decreased risk. This is the author's thesis. Rice believes the governing issue in software security is the need to reduce vulnerability.

The problem with this approach is that life is vulnerability. It is simply too difficult to eliminate enough vulnerability in order to reduce risk in the real world. Most real world security is accomplished by reducing threats. In other words, the average citizen does not reduce the risk of being murdered by wearing an electrified, mechanized armor suit, thereby mitigating the vulnerability of his soft flesh and breakable neck. Instead, he relies on the country's legal system and police force to deter, investigate, apprehend, prosecute, and incarcerate threats.

Consider now the issue of safety vs security. The author makes comparisons using the London sewer, various aspects of driving, and the New York subway system. Especially in the first two cases, these are exclusively issues of safety, not security. What is the difference? Safety incidents happen because a system fails. Security incidents happen because an intelligent adversary exploits a system. The outcome of the London sewer and driving cases would be much different if the Nazis were bombing the sewer system or Mad Max was shooting at cars or blowing holes in pavement. In short, the author cannot suggest that an approach that works against a safety problem is going to succeed against a security problem. Security problems are more dynamic because the threat perceives, adapts, and returns in ways unexpected by the victim.

As far as open source goes (ch 6), the author makes several statements which show he does not understand the open source world. First, on p 247 the author states "While a binary is easy for a computer to read, it is tremendously difficult for a person -- even the original developer -- to understand." This is absolutely false, and the misunderstandings continue in the same paragraph. Reverse engineering techniques can determine how binaries operate, even to the point that organizations like the Zeroday Emergency Response Team (ZERT) provide patches for Microsoft vulnerabilities without having access to source code!

Second, on p 248 the author states "The essence of open source software is the exact opposite of proprietary software. Open source software is largely an innovation after-the-fact; that is, open source software builds upon an idea already in the marketplace that can be easily replicated or copied." On what planet?

Third, on p 263 the author states "[O]pen source projects are almost always threatened by foreclosure," meaning if the developer loses interest the users are doomed. That claim totally misses the power of open source. When a proprietary software vendor stops coding a product, the customers are out of luck. When an open source software developer stops coding a product, the customers are NOT out of luck. They can 1) hope someone else continues the project; 2) try continuing the project themselves; or 3) hire someone else to continue developing the product. Finally, if the author is worried about open source projects not having an organization upon which liability could be enforced, he should consider the many vendors who sell open source software.

Why then did I love Geekonomics? Aside from these two issues, the rest of the book is excellent. The legal chapter alone would be enough to justify reading the book. Although I took introductory law in college, ch 5 put the law into context for my professional industry (digital security). The author's discussions of disorder, churn, software buyers as crash dummies, adhesion contracts, strict liability, aero charts as products, and many other areas are spot-on and eloquently discussed. I disagree with the author's recommendation for a vulnerability tax, but the fact we can have the discussion is really powerful. (How in the world could vulnerabilities be measured in order to be taxed? Why weren't auto makers taxed for "unsafe" cars? If cars were being bombed on the highway, would auto makers be taxed? And so on.)

I'll leave the platitudes to the previous reviews, but suffice it to say that you should read Geekonomics. The future of software is legal, and Geekonomics is an incredible way to understand what is happening in our industry.

Anyone that knows me at all can tell you that I am not a fan of Fear, Uncertainty, and Doubt (FUD) in making the case for effectively managing risk. As a professional in the information security business, it is all too easy to use FUD as the "easy way out" when trying to convince people of the severity of vulnerabilities and so on. I am pleased to say that David does not employ this tactic in his book. He makes a very reasoned case, building it with example after example of how poorly software is constructed and how deep the rabbit hole goes in software manufacturers' efforts at liability avoidance.

So far, the reviewers of this book are all "security people". Please know that there are caveats to such reviews - namely, we are always looking for the "aha" publications that tell the rest of the world what we have known for a while now. This is one of those, and it may very well be the first I've really enjoyed while trying to put myself in the shoes of the "average computer user" in the world today. My usual way of doing this is by asking myself "Will my mom understand this?" I'm very pleased to report that my mom could in fact "get" the big picture David is painting here - namely, that software is something we are relying on as a critical part of society today, and it is just as fundamentally flawed as the early sewer systems he describes early in the book.

What's great about this book, aside from the points already articulated by the other reviewers, is that it takes a problem we all know exists (most software is crappy) and forces you to look at it from a number of different angles. How many books do you read in a year that actually cause you to ask yourself questions? Probably very few, I'd guess. This is a book that challenges you to think about things differently; for instance, a Windows system crashing is not just a "Blue Screen of Death" on your home PC, it's now a critical system controlling a local power grid that just went down. It's not just a poorly-written piece of Web server software, it's a perfectly viable avenue of electronic data theft. And by the way, this little problem affects every one of us. Bravo, David, you've done a great job here. I tend to agree with Richard Bejtlich that a "vulnerability tax" is somewhat infeasible, but at least we're having some interesting conversations. Change usually stems from these, and change is exactly what's on the menu.

In the interest of full disclosure, I work for a large multi-national software company and of course this book appealed to my professional interest.

Before my purchase I explored using the "Look Inside" feature and decided to order. The statements on the cover, the reviews and promises of "How to finally solve the problem" were promising and I was excited to receive my Amazon package.

The first chapter is a lengthy discussion on concrete and it's use in the London sewer system. Interesting but off topic. I assume that this was to set the stage for the rest of the book. As another reviewer noted, and seemed to enjoy, the book is a series of constant references and metaphors for software. Unfortunately, Mr. Rice spends large portions of the chapter explaining the details of the metaphor, not how it relates to software. The use of metaphors is usually to help make a point without having to explain all the nuances of the metaphor. If this is needed, it is usually better to just explain your point and leave the metaphor out.

This entire book at around 360 pages, feels very early on like a one-hundred-pager that has been stretched to it's length purely for the sake of making the book longer. The chapter dealing with US law is a bore and not neccesary to the author's argument. Talking about software and how it could be affected by the law would have saved my time and his.

The last few chapters finally start to talk about software and Mr. Rice finally starts getting to the point, but he relentlessly references his early chapters. When doing so, instead of just saying "As discussed in Chapter 2" he insists on "As discussed in Chapter 2: The start of the boredom and my thoughts on the US Interstate with a vague reference to how roads and cars are like software", needlessly adding to the pain of reading.

One other nit-pick about the formating: There is use of sidebars throughout the book, which normally I am fine with. Unfortunately, they are usually right beside the original text, and end up being duplicate reading (another lengthener?). They fail to help illuminate the point, possibly because the first 80% of this book only dances around the point.

Overall, this book was disapointing. The overall point is good and I do agree with the author, but this was a painful read. To read this book was like talking to that one guy in the office that can't take a hint that you need to go and continues the conversation for his own benefit.

Save your $30.00 as one line can sum up the argument here and save you from having to read a painfully monotonous book (spoiler alert!): Software producers currently take no legal obligation for their products and a mixture of legislation and the court system should be used to keep them in check.

This book offers one of the most comprehensive and rational arguments for fundamental changes to the way software is developed and made commercially available. In addition, the author provides several alternatives for these fundamental changes the business of providing software along with a recommended approach that is practical and thoughtful.

This book is an unnecessarily long political position paper with the apparent intent of swaying public opinion rather than educating and informing practitioners in the field. The author fails to present any practical solutions to the problems he belabors and the information presented is of extremely limited use to a experienced software security engineer. To be fair, however, software engineers are not in the apparent target audience and would likely be alienated by many of the assertions made in the text.

The title of the book is completely misleading and has a very tenuous connection to the actual contents. "Geekonomics" would seem to imply some extent of actual economic analysis of insecure software, but there is exactly zero in the book along those lines. There is nothing to educate or assist a person attempting to perform a software security cost benefit analysis or calculating residual risk of a vulnerability, which would have been the expectation based on the title. Additionally, the subtitle "The Real Cost of Insecure Software" would seem to indicate that the book was focused on software security, but the primary examples and arguments presented are actually regarding software safety rather than security. These are two distinct and separate fields of study and the author does not seem to understand or appreciate the difference. This is a serious flaw.

The primary thesis of the book is that software is bad, the people and companies who provide software are negligent, and that licensing of software developers and unrestrained liability in the courts is the solution. Clearly the author is passionate along these lines, but this simplistic solution is presented without any actual supporting evidence that it would solve the problems outlined in the book. The author fails to identify or cite any examples of software done "correctly" and does not establish any credibility that he has experience either developing or marketing software products.

The ironic thing to me is that I really wanted to like the book and actually appreciate some of the out of the box "Big Ideas" presented. For example, the concepts of recognizing and mitigating "Software of Unknown Pedigree" (SOUP) is of particular concern to software security engineers, and I believe that the author may deserve credit transitioning the nomenclature from the FDA document where it was coined to the broader security community and that acronym has been popping up at more and more security conferences since the book was published. Other ideas fell flat to me, such as comparing the licensing of prostitutes in Nevada to the lack of licensing of software engineers, which was entertaining but never actually seemed to make a salient point.

I can see how the book would have great appeal to presenters at security conferences, as many of the outlandish analogies and examples in the book would make for entertaining presentation source material. Indeed, I purchased the book on the recommendation of one such speaker and it clearly has its fans.

Geekonomics relates to a topic that has been on my mind lately. Summarized, this is the fact my primary goals from employment amount to:

Secure income for my family.
Ensure as much as possible my potential employment in the future.
Position myself as much as possible to be able to spend time with my family.

With those goals in mind, if I take inventory of my talents they amount to the fact I am able to identify and simplify root causes to problems relating to computing issues and come up with solutions utilizing the resources available.

What this amounts too is I build things that work.

So, with those primary goals in mind (and yeah, there are a number of secondary goals that I am glossing over) coupled with the defined skill set and the current state of the market, I have determined there is more opportunity in building defenses (technical or policy) for systems worth protecting rather then building systems worth protecting.

And that is sick really. Why is it more lucrative to protect systems rather then to build systems?

The market pressures that have lead to this situation, and the potential steps that need to be taken to correct it, is what Geekonomics are about. And its a fascinating topic.

There are some problems with the book that amount to nits. For instance, the formatting annoys me. It utilizes "call out" boxes like magazines on a regular basis. I always have seen these boxes as a technique to incite users to read sections and makes me wonder why this was used. All it did for me was disrupt the flow of the book for me. Related to this, the quotes from other sources is in a large font that just comes across as weird. Last nit is the use of endnotes rather then footnotes. I find endnotes next to worthless.

Really though, you don't read a book like this for typography, it is the content that matters. And the content in the title is great. The questions that are raised in relation to the lack accountability are very valid.

Geekonimics is well worth the time to read.