- It's the applications, stupid
- Will a whitelist save personal computing?
- Thousands of Web sites under attack
- To solve the unsolvable problem
- Re-thinking the security of virtual machines
- Security Development Lifecycle trumps code complexity
- Is your Web site FIPS compliant?
- Computer security: Why have least privilege?
- Strategic security: Get a handle on authentication
- Control user installs of software
February 29, 2008 | Comments: (0)
Security Development Lifecycle trumps code complexity
In last week's column, I talked to Bruce Schneier about complexity, one of the main reasons it will be hard for computer security to improve in the future. As software becomes more complex, in terms of more lines of code or functionality, the harder it becomes to stay secure. More lines of code mean the potential for more security bugs. Increasing feature sets means more opportunities for programs to be used and manipulated in unexpected, malicious ways. In general, I wholly believe in this axiom, but it doesn't always have to be true. In fact, there is empirical evidence that better coding practices can more than offset the complexity argument.
Michael Howard is the co-author of several books on Security Development Lifecycle (SDL), and he's principal security program manager at Microsoft. (Full disclosure: I am a full-time employee of Microsoft.) He, like myself and thousands of Microsoft security employees, cares more about computer security than allegiance to the company. We call a spade a spade, even when it doesn't always reflect well on Microsoft. Luckily for us, security is a top concern at Microsoft, despite what some people will tell you. It may not be the only decision point, as it is for OpenBSD, but it is as important as any other initiative the company has, if not more.
Michael is heavily involved in Microsoft's use of SDL in its own software. And the results of SDL has meant fewer found vulnerabilities in SDL-developed software in the same time periods as compared to pre-SDL software versions. Michael's article starts first by referencing Jeff Jones' blog entry comparing Windows Vista vulnerabilities to those of Windows XP and other first-year OS releases.
There is no doubt that the number of vulnerabilities in Microsoft's software is going down despite increasing complexity. Critics, including some who are sure to write heated e-mails in response to this column, constantly blast Jeff Jones' figures. I don't know why -- he uses industry-accepted figures, grabs his numbers from external, independent sources, and compares apples to apples in terms of default software and feature sets.
Some critics say that a single metric neither means everything nor tells the whole story. I agree. What I won't accept is that it doesn't mean anything. I don't care how much you hate Microsoft, and the record still needs lots of improvement, but the number of found vulnerabilities is going down, year after year. SDL is working.
Microsoft SQL 2000 had 10 vulnerabilities, the last in early 2004; Microsoft SQL 2005 has had none. Internet Information Services (IIS 5) had 12 vulnerabilities; IIS 6, released in March 2003, has had five.
Even in the most heavily attacked Microsoft products, with high found vulnerability counts, the overall trend is positive. In 2003, Internet Explorer 6 had 24 vulnerabilities versus Internet Explorer 7's 17 in 2007. IE is tracking nearly dead even with Mozilla's Firefox 2.0, built as the "secure alternative" browser. It might not surprise you to learn that Window Snyder, Mozilla's CSO, is a heavy promoter of SDL.
All of these statistics are not just to inflame anti-Microsoft zealots, but to promote two points.
First, although complexity is the enemy of security, increasing complexity doesn't always mean more vulnerabilities. If your software security coding practices are nonexistent or hugely inconsistent, SDL practices can offset the increasing complexity problem, at least for your product. Increasingly complexity may still make the Internet an unsafe place, because a gazillion new products and protocols are being invented every day, but less because of your product.
Second, if you're a developer and your company is not using SDL, it's time to get on it. There are books on it everywhere. You can search on titles by Michael Howard or look for other books on writing secure code and/or threat modeling.
If you want to improve your company's security programming, teach SDL and build it into the company culture. It might take a little while to get the ship turned around, but once you do, the results are tangible, and they'll benefit everyone.
And contrary to popular belief, Microsoft wants all companies, even tough competitors and open source advocates, to write more secure code. More secure programs make a more secure Internet, which benefits everyone and every platform.
A rising tide lifts all boats.
Posted by Roger Grimes on February 29, 2008 03:00 AM
RATE THIS ARTICLE:
-

- COMMENTS
TOP STORIES
Microsoft's post-Yahoo optionsNet neutrality bill introduced
MS adds $3 million to Big Easy
AMD's Java improvement efforts
Leopard at 6 months
Intel still investing in WiMax
Yahoo tests aggregated search
Developers vs designers
Sun defends JavaFX Script
Botnet spams 60B a day
ADDITIONAL RESOURCES

- Application Security: Threats and How to Counter Them
- Why Linux Threats Mean Business
- Minding the Machines: PC Disaster Recovery for the Enterprise

- Protect Your Data with SSL
- Prevent Your Next Microsoft Exchange Outage
- 11 Myths About Microsoft Exchange Backup & Recovery





