I’ve written in the past about the areas where you need to implement security. My personal focus is network security, because my primary interest is in network firewalls, especially the ISA Firewall. However, there are many layers that need to be taken care of before you can say that you’ve implemented defense in depth security policy. I would argue that the most important consider is the security of the software deployed. In other words, is the software itself secure?
Building secure software is not magic. It’s the result of hard work and dedication to secure software development principles. Many software developers depend on penetration tests and security bugs found in the software after it is released. But is that the best way to do things?
To build secure software, you have to make sure that the software is created with security in mind. Security needs to be built in during every step in the process. From the planning phase, to the development phase, to the testing phase, to the post release phase, security procedures needs to be built in so that security bugs never appear in the first place.
This is where the Microsoft Security Development Lifecycle (SDL) comes in. The SDL includes a number of processes and procedures that can be used throughout the entire lifecycle of a particular software product. Security isn’t something that’s taken care of at the end of software development, where pen testing is used to find any security vulnerabilities in the software. Instead, security is built in each step of the way, so that a proactive approach is used to prevent vulnerabilities from ever appearing. Of course, pen testing is still used, but if the SDL is properly employed, very little value should come from pen testing.
The figure below shows the number of vulnerabilities for the first year after release between Windows XP and Vista, as well as other operating systems. As you can see, just comparing Windows XP and Vista shows a 50% reduction in vulnerabilities. And when you compare Vista to other operating systems, it’s clear that the SDL makes a profound difference when it comes to creating more secure software.
Some might argue that just counting vulnerabilities is not the best way to measure how secure software is out of the box. I won’t argue for or against that point. However, if you’re choosing between Microsoft and another vendor, just ask the other vendor what policies, processes and procedures they in place that insure that their software is secure by design, and have them compare their processes with the Microsoft SDL. If they can’t answer these questions, or give you The Party Line ( this is FUD, what does Microsoft know about security, etc) then consider the potential (and hidden) security issues with their software.
For a great discussion on this issue, check out:
For more information on the Security Development Lifecycle:
Thomas W Shinder, M.D.
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP – Microsoft Firewalls (ISA)