Software Liability, World of Warcraft, and the Principles and Practice of Engineering Exam posted by Rick Howard

Filed in: Software Liability

One of my colleagues at iDefense, Sean Larsson, and I were discussing software liability last week. This popped up around the water cooler because Toyota executives admitted that software glitches caused some of the brake failures that have been in the news lately.

From my take on the US zeitgeist, most people are shrugging this off as just another big company not executing the proper due diligence on its products, but this situation is different. This is a software problem and one of my pet peeve topics.

As a computer scientist, I am embarrassed that my field has not developed into a profession more akin to our civil, mechanical and electrical engineering counterparts. Those engineers have to attend at least a four-year college program sanctioned by the Accreditation Board for Engineering and Technology (ABET), pass the Fundamentals of Engineering Exam and then, after several years working for a licensed engineer, pass the Principles and Practice of Engineering Exam before they can call themselves "professional engineers." Many software development companies, by contrast, will allow anybody who can get a program to compile to work for them. Professional engineers build bridges, spacecraft, dams and power grids without risk of life or limb to the general populace. When somebody does screw up though, there are consequences for that engineer and most likely everybody that works for him or her.

Computer scientists, by contrast, have no equivalent professional program. If they are lucky, they get to attend an ABET school for computer science, but that is about it. Until recently, if they screwed up, these computer scientists just went back to their computers and published a patch for software that should have worked in the first place. There are no consequences for building bad software, no outside organization that can uphold community standards as some do for professional engineers, doctors and lawyers.

Don't get me wrong. Software developers have created some beautiful pieces of code over the years. There are, perhaps, an infinite number of examples you could point to that would make you say to yourself, "Wow, that is amazing." Off the top of my head, here are three relatively recent examples: the Google search engine, the WolframAlpha knowledge engine and the World of Warcraft massively multiplayer online role-playing game (MMORPG). For you gamers out there, you know I had to slip in a game for my list.

Here is the rub. Even though we have built some amazing automation over the years, we still cannot eradicate the most basic of security coding errors: the "buffer overflow." This problem and others like it have been around for 50 years because they are "too hard" to fix. Wait, that is not correct. We absolutely know how to code without introducing buffer overflow errors. Every college student in CS-101 is taught how. The problem is that, as a profession, we do not have the will to enforce it. Tell that to the NASA engineers who put people on the moon and brought them back safely.

Thus, you can see my embarrassment. On one hand, we put people on the moon. On the other, we still have buffer overflows. Perhaps the computer scientists of the world, me included, could raise our sites a bit.

As Sean says, there is hope. It is ironic to me that we might have Microsoft to blame for any success in this area. Its Trustworthy Computing Security Development Lifecycle, although not perfect, is the model for the industry. Indeed, Adobe adopted similar practices about two years ago and is working to get it right. Gary McGraw's book, "Software Security: Building Security In" is a treatise on best practices that software houses and internal software development programs can use to improve their secure coding practices. (By the way, Gary works in the building adjacent to ours in Virginia. I met him at the FS-ISAC conference last year). All of this is a long way from passing the Principles and Practice of Engineering Exam for computer scientists, but it is progress.

As Bruce Schneier said in 2002, "[C]omputer security is at a crossroads. It's failing, regularly, and with increasingly serious results." The Toyota example is just the latest and probably the most obvious to the general populace. Eight years after Schneier's blog and 50 years after computer programming began in earnest, we still have not figured out how to legitimize our profession.

(No Comments)