September 08, 2008, 3:54 PM — Now something completely unrelated to VoIP: Reason behind all vulnerabilities in software! I read an article that explained how vulnerabilities are basically created by the fact that people tend to drift from good development principles into practices that are just simply Fun. The engineers among us know that software development can be enormously interesting, something you would happily even do in your leisure time. But can fun be converted into reliable software?
The Article That Made Me Think
"Software vulnerability due to practical drift", article by Christian V. Lundestad and Anique Hommels (2006) attracted my attention because they had cited my old journal article published in the very same publication several years ago. I read it immediately when I received a copy. It had a very different perspective to software vulnerabilities than what I was used to. I wanted to share my thoughts with the rest of you, hoping that you would express your opinion on the topic (comments are welcome!).
The Reason For Vulnerabilities - Take One
I have tended to first divide vulnerabilities in the three basic categories leading to the creation of the vulnerability, based on the phase of introduction: design flaws, implementation flaws, and configuration/integration flaws. Design flaws are mistakes in the principles on how software should work (e.g. understanding customer need and software complexity). Implementation flaws are simple programming errors either due to ignorance, rush, missing quality assurance steps. Finally configuration flaws are mistakes in deploying the software.
Design flaws and configuration flaws are basically always created because of lack of communication between parties involved. Implementation flaws are almost always simple typing errors, or created due to bad skills in programming. Configuration is often a usability issue. Quality assurance techniques try to find all these, but are almost always lacking because of the time-to-market requirements, and bad finances in R&D (lacking QA budget).
The Reason For Vulnerabilities - Take Two
Good software development practices do not create vulnerable software. If strict processes and development techniques are used, there would not be any software vulnerabilities. The reason for vulnerabilities is the deviation from the right path. Strict software development principles are not always fun, and software developers want to have fun at work.
Still, the flaws are created by people. "Hackers" are never good R&D people, and good managers know that. They are good at fast prototyping, and in project management where they are allowed to innovate. Good R&D people are tinkering people, who are interested in small details and quality. A good project is created by combining the best skills of each involved person. And everyone can have fun, their own way.
And The Answer Is?
I loved reading the article as it gave a lot of good thoughts, and a fresh new perspective to a topic that I have been working with for the last decade or so. But what was my take on it? I have broken, or seen our customers break tens and tens of carrier grade software solutions that have used all the best practices in development.
Pointing a finger at the people behind the management, design, implementation or testing of those products just feels a bit too easy. Same applies to blaming a poor engineer that became too sloppy due to enjoying his work too much. A required step, such as a code audit or a fuzz test, might have caught the flaw. A missing customer interview, or a manager that did not listen to requirements could have saved the delivery.
Maybe some of you can feel that you could have done a better job and avoided a flaw or two with that, but all of us know that it would come with a cost. Finding correct people, training them, buying all the best testing tools, and finally succeeding in the change management is never easy. Show us a perfect software, and the hacking community will immediately break it. The world is not black-and-white. There is no such thing as secure software, but some software is tougher than the rest. Let's aim at that.
