Slashdot Mirror
Geekonomics
Ben Rothke writes "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." Read on for Ben's take on this book.
Geekonomics: The Real Cost of Insecure Software
author
David Rice
pages
362
publisher
Addison-Wesley
rating
9
reviewer
Ben Rothke
ISBN
978-0321477897
summary
How insecure software costs money and lives
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.
Ben Rothke is a security consultant with BT INS and the author of Computer Security: 20 Things Every Employee Should Know.
You can purchase Geekonomics: The Real Cost of Insecure Software from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
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.
Ben Rothke is a security consultant with BT INS and the author of Computer Security: 20 Things Every Employee Should Know.
You can purchase Geekonomics: The Real Cost of Insecure Software from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It's spelled Britney Spears.
we live in a society that tolerates 20,000 annual alcohol-related fatalities (40% of total traffic fatalities) and cares more about Brittany Spear's antics than the national diabetes epidemic.
Not to mention reading slashdot, going to the movies, etc, etc.
Software written for most industries where human lives could conceivably be on the line IS under the watchful eyes of regulators. As an example, if you are going to write software that goes into an airplane you can expect to have your work audited by the FAA. Similar circumstances exist for most other industries where a software failure could cause loss of human life or similar catastrophes.
Just to get in the troll everyone is going to use, even though it's pretty much a load of bollocks:
"This book could be summed up in three words: 'don't use windows'"
I suppose that should be suffixed with some 'tard thing like "lol!!111!!1one"
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Few people (rightly so) would tolerate Boeings or Airbuses that fell out of the sky through faulty software.
And yet, as a former coder then vendor, I always found it hard to get people to pony up for better education for programmers, analysts, project managers, or better coding tools, exhaustive testing protocols, whatever.
Now as a consultant, I face the same struggle getting people to be serious about backups, redundancy/eliminating single points of failure...
As long as it's not their head on the block, even senior managers will most often favour commercial expendiency over prudence. This in the face of many high-profile disasters that cost a lot more to put right than they would have done to do properly.
Regulation is a means by which the established companies keep possible competition from developing. MS can pay for that overhead from pocket change; can Open Source developers?
In my experience there is so much feature creap in software projects that there always seems to be that last feature that needs to get squeezed into the next release at the last moment and there isn't time to test. "lets just hope that 10k line module works and is secure. Even if it's not, we can always release a SP after we have the product on the market". It is even to the point where major software companies (MS comes to mind) have a concept of Zero Bounced Bugs. That is the point where the bugs getting fixed equals the bugs being found. If no "major" bugs and you've reached ZBB you ship. Now I can see you can't wait forever to ship, but there is this inherit acceptance of flaws in software that you won't see in say bridge building.
Companies don't spend much time on security because features are what the customers want. If you want security and unlimited liability, by all means ask for it. Of course, it will cost you extra, due to the need for security audits and the outrageous cost of liability insurance, but you can certainly get it. If you pass a law to require perfect security and liability, the cost of software will rise even higher than it is today. Take your pick.
To get a loan for my $50,000 PC which requires $300/month insurance to operate.
I hope to pass my operators test so I can get my license.
what, a whole book review on software development, and not a single mention of open source? how did this make it onto slashdot?
OSS cracks aside, it would be nice to see if the book talks about that side of things at all; the impression i got from the review is that there's not much distinction drawn between software licensing and development models, and that it's all sorta lumped in together.
so if, as the book seems to suggest, software development were regulated more closely, who would be accountable, or audited, or whatever, for an OSS project with heavy community involvement that's seeing commercial applications? or with an OSS project that gets implemented as part of a for-profit piece of software?
i'm curious, because i have less than zero experience in how this stuff actually works, but it seems like it would be a weird situation. anyone have any insight?
/. is what happens when geeks talk. get used to it.
Is to waterboard developers until they stop helping terrorists and criminals.
If you haven't made a developer cry, you've wasted a day.
This is where the real 'Software Engineers' come into play.
A licensed professional is responsible for the bulk of the software development work, and can be held responsible jointly and severally in a court of law for any software defects resulting in loss, or injury.
For most software, it's ok to let the code monkeys loose at it. You pay your money, you take your chances (excel bugs anyone).
For mission critical stuff, you can't let just any highschool drop-out come programmer tackle it. REAL university degrees, and REAL experience are demanded.
Code monkeys will always have a future, but software engineers will generally be the ones to count on if software quality and reliability enter the equation.
I say the market itself will solve the problems with software security. New companies or new software products will only replace existing ones if the new ones are better. And like the book mentions, "better" is often measured in features. However, if enough damage is done with the current software flaws, some of the new features will include better security.
Example: Company A is sued by Customer B when Attacker C exploits a hole in Company A's software resulting in a financial loss for Customer B. Like the book mentions, Customer B usually has no legal grounds to sue. However, if this happens multiple times, Customer B may get wise and ensure proper contracts when entering new agreements.
These contracts could be required by customers when dealing with both closed source and open source companies. Buying a support contract from Sun for MySQL _could_ include certain software security requirements. And if Sun does not support this service, a business opportunity exists for another company.
Oh Christ! I hate made up words like that. They make me think of Reaganomics and those "FUN" days.
Ask not what you can do for your country. Ask what your country did to you
This is absurd: does Firestone prevent a knife from flattening their tires? Does MasterLock prevent someone from using bolt cutters on their locks?
Trying to implement software that will prevent a malicious attacker is a losing battle and not worth spending money on -- look at all the money spent by the RIAA on software-based copy protection. That money is better spent in court prosecuting the crackers.
Bad software costs us 180 billion dollars a year? That would be about $600 per person in the US. Per year. I call bullshit. Unless you are going to claim that Mozilla is costing my family money because it allows me to waste time on /., this just doesn't make a shred of sense.
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
OK, so now that doctors are operating at near-zero profits, malpractice lawyers need a new profession to plunder. Wonderful.
Luckily, its much easier to switch out of software than out of medicine (given that one has invested 8+yrs to a career in medicine.) So the smart folks switch out, leaving the weaker folks to create more buggy programs. A race to the bottom!
In general, computer software for mission-critical devices would be regulated by the same agency that regulates the accompanying hardware.
Think FDA, FAA, NRC, etc.
Now, systems that are nominally non-critical but which in fact are used as infrastructure may be unregulated and subject to the very problems described in the book.
For example, most smart cell phones aren't engineered for untra-security. If I am a terrorist and I know ACME Electric Company uses the Plinko 100(TM) cell phone to communicate with its field operators, I can hire some cyber-criminals to schedule an attack on their phones at the same time as I set off a few bombs that take out a few major transmission lines.
If ACME realized its phones were mission critical and used a hardened or at least fault-tolerant communications infrastructure, it would be a lot harder for me to knock out their communications when they need it most.
The problem isn't insecure computers per se. The problem is relying on them without understanding the risks and the consequences of failure.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Why is it that any time someone talks about software engineering they always bring up bridge/house/skyscraper building? Yes, Joseph Bazalgette used "formal engineering practices" to build London's sewers, but where did these formal practices come from? Why yes, through trial and error. Thousands of years of trial and error. Use concrete. Yes, it makes sense looking back because it worked, but what if it didn't work? What if the concrete failed? Or, What if he used clay pipes instead? Then we'd be saying "[insert name here] used formal engineering practices to deal with the city's growing sewage problem. Some guy before him failed miserably though." We simply haven't built up the software engineering toolbox yet. Software hasn't even been around for 100 years! But we're learning, and if you look in specific industries like medicine, banking, and avionics spring to my mind, they all spend billions of dollars to make sure their software works correctly because being correct for them is worth the cost.
Flaws in books can have disastrous consequences if someone depends on them to be flawless.
Imagine a repair manual for a gas stove that said "blow out pilot light, turn on gas, wait one hour, invite your friends over, and light a match." Sure, it might not steal credit card numbers but in the face of an ignorant and trusting user, it could prove fatal nonetheless.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
But this isn't because we don't care.
Obviously, all those things I listed show that people do care; however, they are going the wrong things to address the problem. We have allowed special interests like MADD, who are modern-day temperance societies, dictate these changes to us with little review or oversight. It has been statistically proven that fatalities do not decrease with aMaybe we need to do more. But remember that there will always be people who insist on doing the wrong thing, and finding a way to do it.
Gamingmuseum.com: Give your 3D accelerator a rest.
The reference to Ralph Nader's "Unsafe at Any Speed" is a good one -- both ways.
/. can be updated at regular intervals (like keeping the tires inflated), and most of us take advantage of those updates to keep our systems clean.
Giving them both their due, neither cars nor software are perfect. Both could stand improvement. I don't see anything in this world that couldn't use a little improvement.
On the other hand, "Unsave at Any Speed" unfairly characterized Chevrolette's Corvair as poorly designed when the real problem was that many Corvair owners took no responsibility for routine maintenance. The Corvair has been called the poor man's Porche because it was a well balanced car that would perform well if its tires were properly inflated.
In the same way, much of today's software is amazingly good, especially considering the cost to acquire FLOSS. Most of the software used by people who use
Joe Sixpack wants to surf his p0rn; he doesn't want to "waste time" with those pesky software updates. If his tires run flat he'll just buy new ones. Now let him go where he wants to go!
When was the last time we held car manufacturers liable for damage caused by potholes? Do we expect car manufacturers to keep us safe from the consequences of driving over nails or off a clif?
Yes, everything could stand some improvement, especially those silly shrink-wrap or click-wrap license agreements. I still don't see how the software that is not guaranteed to do anything useful has to be treated like the crown jewels. But that does not seem to be the focus of "Geekonomics." Let's work on reducing the targets for malware while we thank those who provide the software that works as well as it does.
If it costs 10x as much to fix a problem than prevent it, but for every $100 you spend on prevention you only prevent 1 failure, you are in the hole $10. That's rational math at work.
If you are a greedy-bastard manager and you expect to be in your position for only a few years, all you care about is the failures that will come back to haunt you. You don't care if spending $5M now will save $1M in expenses over the next 5 years but save an additional $20M 10 years down the road. By then you and your greedy self-interested wallet will be out of harms way.
On the other hand, if you are a human manager with a conscience, you'll look at things long-term and either ante up now or make sure the problem is addressed before it is too late.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The /. summary talks about three completely different things: regulation, licensing, and liability. Regulation seems completely nutty to me; legislators don't have the expertise to do it right, and if they do it wrong they could easily, e.g., strangle the open-source movement in the cradle. Licensing historically has has very little to do with safety or quality; in my state, IIRC, hairdressers are licensed, and it's basically a way of reducing competition in the labor pool so that the hairdressers who lobbied for the licensing requirement can make more money. Liability already exists, and has nothing to do with government regulation. If the software in your car malfunctions and you end up a paraplegic, you certainly can sue the company that wrote the software.
I think the big problem is that the way the software market works, buyers tend to make a lot of bad choices. Often that's because there just aren't that many choices; the MS monopoly means that many people don't perceive any other choices besides windows as being viable. Sometimes buyers make bad choices because they aren't well enough educated about software to know what to look for. People are also reluctant to change once they're locked in to a particular piece of software, even if it's bad. Government intervention isn't going to change any of this.
Find free books.
IBM and other mainframe- and mission-critical-embedded-systems vendors know a lot more than MS about how to do it right ... for a price.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'm a little surprised to find myself saying this, but I think that the free market will be able to sort this one out. Regulation is already in place to keep airplanes from falling out of the sky; if companies are losing money because of poorly-designed software, that should be enough of an incentive to purchase more secure software.
There is a market out there for run-flat and solid-rubber tires.
There is also a market for bolt-cutter-proof locks.
Of course, there are ways to defeat them, but they require more effort than a knife or a set of bolt cutters.
You get what you pay for.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'm going to claim that Mozilla is costing your family money because it allows you to waste time on /.
Welcome to Slashdotaholics Anonymous.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
In the early '90s, I was in high demand as a software engineer who could build high-availability systems on OpenVMS and Unix. Then WinDoze started leaking in, and my bosses, and their bosses, starting saying things like "Why should I build this new app on OpenVMS when I can get a Windows box for $2k and it comes with a free web server?"
The answer, of course, is Reliability, Availability, Securability (RAS).
But no, ever mindful of immediate costs and features, and completely bind to the 5-year costs, they forced us to change to WinDoze. And they're still demanding feature improvements and cost reductions instead of RAS. Firing those pin-heads and giving us our tools back would go a long way towards improving the disaster that is today's software development environment. In fact, you can tar & feather 'em for the remaining multitude of sins they've foisted upon the software world. Yeah, out-sourcing is a great way to build secure software.
New Music!
If we are looking at the cost of bad software, where does this leave Teh Lunix?
Seeing as how Munich is now a living testament to the disastrous limitations of using Teh Lunix, will this book be the final nail in the FOSS coffin? Or is this just another "TEH OMG!!11! TEH FOSS ROCKZORZ AN TEH MIKKKR0$$$L0TH SUXXORZ!!111!!1" book nobody will ever bother reading?
Why keep referring to "software manufacturers"? Calling what software engineers do "manufacturing" is a broken analogy, because creating software is really about _design_, not manufacturing. Manufacturing is the easy bit at the end where you burn CDs or distribute on the Internet.
"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. "
Pipe dream... not quite...
It just hasn't led to catastrophic loss of life...yet... when it does thats when we'll take notice... right now most of us are living week to week on our paychecks trying to get ahead... think of the public as what Morpheus talked about in the matrix...
"...You have to understand, most of these people are not ready to be unplugged. And many of them are so inured, so hopelessly dependent on the system, that they will fight to protect it."
When a 6 block radius of New York City is turn into dust, thats when we'll take notice... at least for a few weeks.
-dml337ira (Resident ground Zero)
"First the good news - in a fascinating and timely new book Dupenomics: The Real Cost of Slashdot Dupes, Anonymous Coward clearly and systematically shows how Slashdot Dupes are a problem of epic proportions, both from an economic and safety perspective. Currently, Slashdot readers have very little protection against Slashdot Dupes and often the only recourse they have is the replacement cost of the media. For too long, Slashdot Editors have hidden behind a virtual shield that protects them from any sort of liability, accountability or responsibility. Dupenomics attempts to stop them and can be deemed the software equivalent of Unsafe at Any Speed. That tome wanted us against driving unsafe automobiles; Dupenomics does the same for Slashdot Dupes."
This was not a dupe.
I never read "Unsafe At Any Speed", but I remember it as the book that first made Ralph Nader famous. How much impact did that book actually have anyway, aside from terminating production of the corvair.
The first car I ever bought was a '62 Corvair. That was when I was in the Navy and stationed in Japan (I bought it from another GI). I paid $75 for it and it definitely had a problem with exhaust getting in the cab. I always drove it with the windows down. One thing that I recall was a time when I gave a Japanese bar girl a ride in it and she hesitated because it was a corvair. Even she had heard of "Unsafe At Any Speed". But then, she was one of the more thoughtful bar girls. That corvair was a great car to drive though with its air-cooled engine in the back. I've never had a car since that could corner like that baby.
So, how much influence really can we expect a book on software safety to have? I'm all for educating the public, and I'm not saying the author is wasting his time writing it. Just because I'm cynical doesn't mean I say don't try.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
Here's another take that argues against liability laws: http://lwn.net/Articles/247933/
Farming, manufacturing has waste and other write-offs. What kind of percentages are wee talking about for various industries? 5%? 10%?
This Amazon.com review mentions Mr. Rice's opinions on open source:
Geekonomics reviewed by Richard Bejtlich:
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.
David Rice responds on his blog.
Yeah, what could possibly go wrong?
How did this get flagged as flamebait? This is exactly the kind of crap regulation does. Do you think for a minute that regulation in software is going to do squat against the giant coffers of corporate America that can afford to pay out fines and such? Now what happens when someone uses an Apache server for something critical, and it turns out an Apache error caused the failure...now who is going to get shafted? The regulation idea is a nightmare waiting to happen with a huge chilling effect. Let us also ponder who might be in charge of said regulation... I mean...government regulation would be managed by government right? Anyone remember Sen Internet Tubes Stevens take on technology?
I'm sorry but regulating something like this is almost criminally stupid. I agree with there needs to be better consumer protection, and I don't think companies should get away with "you can't blame us if you actually use the product you purchased from us and it doesn't work". No other industry can say "you can't sue us if the product you purchased from us does not do what it was intended to do". That doesn't take more regulation to fix.
The only change I can believe in is what I find in my couch cushions.
Google for "paruresis" and read up.
The problem is that with the rise of 1) mass e-commerce, e-government and Internet banking, and 2) Internet-enabled desktops, now EVERY piece of conceivably internet-facing software installed on a consumer desktop carries the risk of exploitation, criminal intrusion and identity theft.
Yes, a security hole in a web browser won't directly cause loss of *life*. However, what it *can* do by allowing a trojan in is:
a) Drain all your life savings from your bank
b) Place illegal pornography on your computer, leading to serious prison time
c) Propagate spam, worms, viruses and botnet epidemics
d) Activate your webcam remotely and film you in your bedroom
e) Directly financially support criminal organisations
Those are now serious enough consequences - and given a single security hole in a mass-produced product, easy to reproduce on a mass planet-wide scale - that ALL developers of even the most trivial desktop software need to start thinking in terms of the kind of hard security requirements of banking, military, avionics and medical gear.
But they're not, because they haven't caught up with reality.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
....and the point of you sharing that piece of your health is????????????
I should have added:
e) By installing a keylogger (if you're a telecommuter with a VPN, or if you reuse passwords between home and work systems), potentially gain access to internal proprietary corporate networks, with the ability to conduct industrial espionage or control enterprise automation systems or SCADA networks
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Maybe Microsoft is left their software insecure all these years intentionally, in the hope of securing the kind of regulation that would make free open-source software nearly impossible.
Try building a bridge piecemeal while traffic is driving over it, and where every car driving over it gets a piece of its engine transformed (in visible or subtle ways), and now you're talking something closer to what building, deploying, and upgrading a production software system is like.
'Constructing' the initial version of software, as an isolated system, with no users and no live data, is only the very first step, hardly worth talking about - basically the 'sketch on a napkin' stage of a blueprint. If you're lucky, you've now created something that passes the first iteration of tests and meets the first iteration of the spec. Congratulations, you've given birth to a glorious One Point Zero. Yay you.
Oh wait. Did you think you were done? Hahaha! Now extend and maintain it for thirty years, once you get full-time users, no acceptable downtime, and legacy code and data, and in the face of shifting hardware and OS platforms and data formats and all the rest of the spec changes.
That's where the real software development job starts.
Bridges don't get upgraded every three years. Skyscrapers don't have to be built to be able to morph into giant walking robots. When tectonic plates shift and convulse under cities, we call that a 'huge natural disaster' and send in the National Guard. When platforms change the rules under software, we call that 'apt-get upgrade' or 'applying a service pack' - and expect people do do it every month.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
So, this book blows the problem completely out of proportion, demonizes the producers and calls for more attention from the clueless masses?
Well, let's just get ready to welcome presidential candidate David Rice!
I don't have any moderation points to add to Helevius' karma, but I can send my things for posting an informative article.
Its pretty clear to anyone paying attention that the fact that software vendors like Microsoft pay no price for security failures in their products means that they don't have much incentive to fix them (see Why are there still e-mail viruses? ). So I was inclined to agree with what seemed to be the theme of Geekonomics. But from looking at the quotes above and the authors blog, it's pretty clear that the author doesn't have much of a clue. He tries to excuse this by stating that, well, he's writing for executives, so he can't go into technical detail. This is really just an excuse for not putting the effort in to completely explain the problem. I am in the middle of reading David Leavitt's excellent novel The Indian Clerk , about the Indian number theorist Ramanujan. Leavitt manages to clearly portray pre-World War I England, number theory and academic mathematics. The author of Geekonomics really comes off as yet another consultant whose writing a book to get those hourly fees from those very same clueless executives. I am glad that Helevius has saved me from buying this turkey of a book.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Some of the major software vendors (MS, Apple etc.) have high to very high margins and profits - WELL more than enough to make their software MUCH more secure if they wanted to, at a cost of only a miniscule fraction of their current profits. Nobody said anything about demanding "perfection", that's a strawman or false dilemma (i.e. it's not "choose between 100% or no extra effort") --- the vast majority of the world's software security problems, and associated costs, could be drastically reduced with just a few comparatively small changes (e.g. fix Internet Explorer, for example, a prime infection vector that has been continuously exploitable for over 10 years - fortunately recently decent more secure alternatives have appeared).
Well, that may be true. How much is good software going to cost us if everyone is liable for the code they write?
There are three avenues I can see that a company or individual doing development in the US could take if this becomes law:
1) Pay the costs to develop bug free software.
2) Stop developing software.
3) Move to a country with a less onerous position.
Of the three, the only one that is actually not feasible is 1! Why, you might ask? Because the company must make a profit, thus must sell the software for more than they developed it for.
Yes, the shuttle software has ~0 bugs. The cost of that has also been estimated at $1000 per LOC. Apache, for example, might have around 81852 lines of code... $81,852,000, which is not bad considering! The linux kernel (2.6) ~5.2M LOC. Hmm $5B??? Not to mention the glacial pace that shuttle sw moves. The pace Hurd is moving at would look like light speed compared to changes to any medium to large sized codebase.
But, you might say, what about people who give their software away for free? After all, I just used Apache and linux as examples of what it might cost if commercially developed but they were not! We could just get all that work for free. Free!
Well, show of hands - who wants to give some software away for free and be liable for the results? Put something up as an individual and one lawsuit (even if wrongly brought) is enough to bankrupt you. I guess there is always posting anonymously but I assume any distributor of the software would then be liable. How many projects on SourceForge would be available if either the contributors (non-anonymous) or SourceForge (for anonymous projects) were liable? Likewise e.g. RedHat, could all be held responsible for not only code they wrote but what they distribute if it was anonymous code.
Then there are shared objects like libraries. Is is misuse of the library by the end developer that caused the issue or a bug in the library itself? Or should this have been caught by the QA of the end developer? Are both liable? It could get very entertaining.
So, we may be experiencing $180B loss for bad software, but I happen to think that we might lose much much more if software liability were a reality.
Not that MS, IBM, Oracle, Apple, Adobe, RedHat, etc... would ever allow this to happen.
Please note: Nothing in the above states that I'm for buggy software being written. I believe that we simply don't have the tools to liability proof these types of products yet in a cheap, fast way. We can write good software. We can even write great software. But that one bug you didn't catch is the one they will sue you for.
In fact, how about you can't use a computer anymore because you (yes you!) don't know enough to be absolutely, positively 100% certain you won't loose your identity, catch a virus, or vote for the wrong party.
Oh yeah, and since you don't really know how to drive, there goes your car (BTW, we know that you speed every day - the fines just exceeded your tax bill, sorry!)
And since you don't know how to eat, here's a feeding tube, it will save on medical insurance costs.
Frankly, I think we have too many rules.
How about drop a bunch of the rules, learn how to use stuff, and own up that if it bites you back, maybe it's because your usage exceeded your understanding.
Feel free to flame away. I'm responsible for my actions.
Bill
This sounds good in principle, but a lot of software that we programmers assume has crap correctness is actually being used in critical ways. Excel, for example, is in the pipeline for a lot of engineering and scientific calculations, even though it's riddled with bugs and usability problems. You can say that users should know better, but Microsoft doesn't make clear that Excel is really just a toy, not for use on things that matter.
"Not an actor, but he plays one on TV."
When people are prepared to pay the true engineering cost of secure software you'll get it.
Until then you'll get what you are prepared to pay for.
I really don't understand why people want to have Audi or Mercedes quality but only pay the engineering cost of a Ford.
Superficially they both look the same and behave the same (four wheels, engine, economy, airbags, NCAP safety rating, etc) but when you've driven one you won't be going back to the other (unless you can't afford it).
qwerty
I really hope this doesn't inspire some federal policy maker to require some sort of licensing to write code.
I don't even have a bachelor's degree - but I'm the best programmer in an office full of CS graduates, by their own admission.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
I've seen it happen. A Staff Sargent at the unit I worked in got sent to Leavenworth for downloading porn at work. The sad thing is that he did it on an Major's computer. Not a great idea.
Never mind, I didn't read the GP correctly. No trojan was involved, just an idiot.
This sounds like the same thing bruce schneier came up with in secrets & lies, but possibly to a further degree?
Thomas Galvin
That's the way it is in commercial softwareland, unfortunately.
If no money is involved, you can have all three 'features'.
Linux would probably be an example of a software package having all 3 features mentioned.
The only alternative would be for people/companies to write their OWN operating systems and applications and not leave that task to third parties.
If they are unable/unwilling to do that, they either 'go without' or live with the usual 'this software is provided AS IS AND WITHOUT ANY WARRANTY' legalese that all software really have.
When you get right down to it, only the development machine(s) are guaranteed to run the software created on it/them--otherwise it is not a given the software created will work anywhere else hence the legalese.
What SHOULD be done is reduce ALL commercial, binary-only software EULAs to the following 3 statements.
1) Do not illegally copy and distribute our software. (Our potential profits are preserved)
2) Do not reverse engineer our software. (Our competitive advantage is preserved)
3) Our software is provided AS IS. Use it at your own risk. Your sole remedy is a refund of the price you paid for our software. (Our valuable resources aren't frittered away by expensive litigation)
That's all such software EULAs say anyway so why waste time and resources with multipage EULAs that people ignore/click past anyway?
it's past time, way past time, for us to recognize that software is a crucial component of our infrastructure. and like concrete, steel, electrical work, plumbing etc etc we have to have a means to make sure the job is done right
part of "done right" is that the software does what the specifications say it will do
part of "done right" is that the software does not fail: abend, loop, incorrout, wait state, slow -- what have you
no software maker will be able to stand behind their product unless they have assurance that neither their product or the os on which it is run has been compromised by rats, trojans, spyware, adware, worms, bank robbers,geeks, hackers, goons, snake oil, virus codes etc etc etc
enough already
it is time to slow this industry down and get things right. for a change
now I know what I'm saying here ain't real popular on this board. about as popular as dad showing up at a teenager festival
allright geeks, fall in and get to the position of attention
Parent is spot on. Here's the analogy I use when I try to explain to people why building large software projects with low bug rates is so difficult:
Imagine designing a machine with 500,000 custom moving parts.
Not only that, but every day, dozens or hundreds of those parts get re-designed or scrapped or newly added, and you have to adapt the design of other parts to work with the changes.
Stamping out DVD-ROMs at the factory and stuffing them in a box is "manufacturing". That part is a solved problem. The part thats not completely solved is how to *design* the extremely complex software that now runs many aspects of our society.
Wasn't that the plot to Live Free or Die Hard?
And yet, as a former coder then vendor, I always found it hard to get people to pony up for better education for programmers, analysts, project managers, or better coding tools, exhaustive testing protocols, whatever.
I think this is because it's hard for you to prove the value in any objective way.
As long as it's not their head on the block, even senior managers will most often favour commercial expendiency over prudence.
Right, so let's make it their head on the block. Set up a private entity to certify software as secure. Give each product that's evaluated a grade, much live the gov't A/B/C grading system, but applicable to commercial enterprise.
Now, the software manager is incentivized to buy 'A' software because when the shit hits the fan and he chose 'C', he gets to feel the heat.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)