When you talk to Microsoft technical people (or read their blogs), they talk incessantly about the SDL or Security Development Lifecycle. This is the new way of life at Microsoft that will lessen the number of vulnerabilities in their products. At least thats the plan.
The SDL is a model for software development and maintenance designed to reduce security problems and related bugs and increase reliability. It doesnt end when the product ships; the SDL involves security response planning and execution even after the boxes are on the shelves.
Microsoft has high hopes for the potential of the SDL to reduce—dramatically—the sorts of problems that have plagued their products in the past, and I think the very short-term results are encouraging.
There are updates and service packs to other earlier programs that were developed under the SDK, but look more carefully at the products from Microsoft that were written from scratch under it. Microsofts Michael Howard, who wrote the book on SDL, says that he expects "...I will...look back two years from now and compare Windows Vista to Windows XP SP2 and Windows Server 2003. I do believe there will be a significant drop in both security bug quantity and severity when compared to prior Windows versions. "
Sure, theres Vista, probably the most heavily scrutinized system ever, and its holding up pretty well so far, but theres also Office 2007. Months after it was released, even the nit-picky Secunia has no advisories on it.
This is actually an interesting point, since eEye has made a vague reference to a vulnerability in Publisher 2007. I asked Microsoft about this report and was told that " ...new capability in Publisher 2007 subjects each document to a close review of its schema in a manner similar to the way Office analyzes the new Ecma Office Open XML Formats. Anything in a .pub document which does not conform to that schema—such as in the case of a corrupt or tampered document—triggers safeguards in the program. In the case of eEyes report, Publisher 2007 correctly identifies that the document does not conform to the proper schema and informs the user of such (and prevents the document from opening)." This sounds at odds with the skimpy information in the eEye pre-advisory.
But even if you read the eEye advisory in its most unfavorable light toward Publisher, the overall record of Vista and Office 2007 is good so far. And it could get better if the SDLs post-ship processes live up to expectations.
Last week an article on MSDN (also by Michael Howard) revealed which function calls (many are C runtime calls, others Windows APIs) are banned under the SDL. Many of these functions arent inherently unsafe, but its easy to program them in unsafe ways.
The lists are fascinating. I see many functions I used extensively back when I wrote a lot of code. It seems like almost all of the C string library is unsafe and handy functions like MakePath are deemed unsafe, although at least it has a safe replacement (_makepasth_s) exists. And its easy to see what the difference is and the reasoning behind it: _makepath_s has a parameter for the size of the output buffer, helping to prevent overflows.
Safer bricks dont necessarily make safer buildings, but theres a lot more to the process. Of course not every company can afford to go through processes like this. More casual programming arrangements, like many open-source projects, are at a disadvantage from the point of view of the SDL.
Were beginning to see the results of that difference, for instance in the security records of IIS and competitive technologies like PHP. (Clearly PHP needs something like the SDL.)
So dont focus too much on individual tools like UAC and Windows Defender when evaluating security of a system. Its the more fundamental changes that make the bigger differences.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. He can be reached at firstname.lastname@example.org.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.