Security, Patch Management, and the Future

I've spent the past 2 weeks traveling the country with fellow columnist Mark Minasi, speaking about security matters as part of the Windows & .NET Magazine Security Road Show. We're hitting five cities on this particular jaunt: San Jose/Mountain View, California; Denver; Anaheim, California; San Diego, and Chicago, We’re also stopping over in Redmond for a mind-meld with various security-related groups. (We took the show to six other cities in late 2002 and early 2003--visit http://www.winnetmag.com/roadshows/security2003 for more information about the road shows.)
Since last fall, I've modified my presentation, "The Future of Microsoft Security," in minor ways to adjust to changes in Microsoft's product lines and release schedules. If we do an expected 20-city tour in the second half of 2003, I'll modify my presentation even more. When it comes to security and Microsoft, things change every day.
As Microsoft customers, we like to think we made the right bet technologywise, and certainly Microsoft's applications, servers, and services have been extremely successful for many reasons. However, only the least cynical among us would list security as a reason for adopting Microsoft software. Indeed, I'm astonished to report a sharp dive in the percentage of people at the road show who claim to trust Microsoft, when compared with last fall's shows. In both Mountain View and Denver, no one in the audience raised his or her hand when I asked who trusted Microsoft. Yikes.
The reasons people don't trust Microsoft are complex and, in some cases, a bit disingenuous. One bit of advice I often dole out to Microsoft customers is that they need to remember which side of the equation they fall on: Microsoft's job is to do what its customers want, not vice versa. If we had all been clamoring for integral security in Microsoft's products, the company would have complied years ago. Instead, the Windows OS has evolved into an ever-teetering mountain of software code that's been patched, bandaged, and melded into almost unrecognizable form. Such software is tough to harden, which is one reason Microsoft is developing a new system--Next-Generation Secure Computing Base (NGSCB--formerly Palladium)--that breaks technological ties with the past in a bid to create a new secure environment. In the meantime, we have work to do, so we have to use today's software, no matter how it was developed.
And that brings us to what is, perhaps, the most miserable task facing the people who support Microsoft software--patch management. Security experts blithely cite statistics that place the blame for most security vulnerabilities square on the shoulders of the administrators who should be keeping all their various servers current with security patches. After all, most viruses, worms, and other attacks exploit vulnerabilities that have already been fixed, they say. However, such people have clearly never tried to administer a complex enterprise. Patch management just isn't that easy.
When Microsoft first deployed Windows Update with Windows 98, I thought I was seeing the future. I thought Microsoft would add its other products to this system and eventually open the system to third parties. I pictured the service providing me with updates to Microsoft Office and any other applications I had installed on any system. And as its capabilities grew to include Software Update Services (SUS), Systems Management Server (SMS), Critical Updates, and Automatic Updates, I figured the most egregious vulnerabilities in any software product installed on my systems would be fixed silently and automatically, in the background, perhaps while I slept and the systems sat unused. The boon to enterprises would be almost immeasurable.
Today, this scenario is still a dream. During the ensuing years, I've spoken with many Microsoft representatives about Windows Update; they've reiterated that the company does plan to centralize patch management. But that hasn't happened. Recently, at a Microsoft Exchange 2003 Reviewer's Workshop, one Microsoft program manager confirmed that the next Exchange release, code-named Kodiak and due alongside the next Windows Server version (code-named Blackcomb) in 2006 or later, would indeed integrate with Windows Update. That's a long wait, but at least it's coming. Presumably other products will be likewise integrated, perhaps sooner.
The reason the integration can't happen immediately is architectural. Windows and Microsoft's other products aren't "componentized," so Microsoft must release patches in separate installations for each language version and edition of a product. The first product to overcome this limitation will be Longhorn, the next major Windows version, due in late 2005--but that's more than 2 years away.
So which patch-management options do administrators have today? Next week, I'll look at some interim solutions from Microsoft, including SUS and SMS, as well as some third-party software with which I'm familiar. If you have a patch-management strategy that's more involved than simply cursing Microsoft every time the company releases a security patch, please let me know. I'll pass along the advice.

Small Business Server Follow-Up
Last week's mention of Windows Small Business Server (SBS) 2003 garnered a lot of responses, most of them from people who seem enthusiastic about this version of the product. Your anticipation isn't misplaced: I feel that SBS 2003 is going to be a watershed version of the server and a huge success. This week, during our Security Road Show stopover in San Diego, I'm getting an in-depth SBS 2003 briefing and demo, so I'll have more details to report soon. The contents of the talk will be under nondisclosure agreement (NDA) for a short time, however, so I'm not sure when I can write my follow-up; rest assured, we'll publish it as soon as possible. If you have any specific SBS 2003 questions, however, please fire away; the briefing is Thursday morning.