Yet Another Security Flaw
I really didn’t mean to start this blog with that tone, but it seems that reality is stronger. A security flaw categorized as extremely critical was discovered this week in Microsoft’s® Internet Explorer®.
You might rightfully ask "what else is new?". Security flaws are discovered each and every day. What is the big deal? Well, this is the big deal! Security flaws cost millions to organizations around the world. Let me be clearer about that: security flaws cause severe costs to users of flawed products, as well as to the companies who wrote them. As users, organizations have to keep applying patches to numerous software products and be alert of any new risk. Of course, if a hacker uses the security flaw before it has been patched, the damages could get really acute.
But the manufacturer of a flawed software product also has a lot to lose. Fixing security flaws and delivering emergency patches to your customers on a weekly basis is a maintenance nightmare. I don’t know if Microsoft has special teams for such tasks, but judging from the rate of security flaws discovered in its products, they should. This translates to resources being dedicated to extinguishing burning fires instead of creating new value to the company. And, of course, we still didn’t talk about the bad reputation such flaws cause to a company.
Of course, Microsoft is not the only company suffering from this phenomenon. Security flaws have become a plague. What I find most troubling, however, is that most flaws could have been discovered and fixed (or even prevented) in early stages of development - long before they cause such damages. Ignoring the well-known problem of security flaws when designing and implementing a product is pure negligence. There are numerous ways to prevent such flaws. Many of them are even listed in a book published by Microsoft Press. Sadly, most of them are ignored for most of the time.
Apart from being aware to the potential problems and learning the practices for secure coding, this issue, like many others quality-related issues, requires a quality-oriented thinking. Many security problems should be prevented by design. Others require built-in mechanisms in the code to protect you from falling into common pitfalls. Merely fixing local problems once they are found is not cost effective.
Another way to reduce security flaws is to systematically conduct professional reviews on code as soon as possible. Weekly reviews conducted by someone with good notion of secure coding can dramatically reduce the defect rates, while helping developers to improve their design and coding skills. This is a perfect investment for the long run. In terms of cost, this investment is negligible when compared to the potential damages you and your customers might suffer.
All you have to do as a software producer is do the math: putting more focus on security during development is the most cost effective approach in most cases. The least you should do is seriously consider this issue when starting the development of a new product.
See also my related article on QualityProgramming.org: The Disclaimer.
