A Look at Windows .NET Server Security

As part of a continuing look at the more intriguing new features in Windows .NET Server (Win.NET Server) 2003, I want to examine some of the OS's security improvements. The timing for such improvements is crucial: As I write this, Microsoft has issued 48 security bulletins this year and is on track to beat last year's record 60 bulletins. What a wonderful accomplishment.

Microsoft halted Win.NET Server 2003 development, as well as Windows XP Service Pack 1—SP1—and Windows 2000 SP3 development, for 10 to 12 weeks in early 2002 so that developers could scour the source code for potential security vulnerabilities. The source-code sweep was part of the company's Trustworthy Computing initiative, which grew out of Microsoft Group Vice President Jim Allchin's reaction to the embarrassing late-2001 Universal Plug and Play (UPnP) vulnerability in XP. The company finally grasped the notion that it wasn't developing product security from the ground up, but was simply adding security to products as it would add any other feature. The end result was a patchwork of code that was often easy to compromise.

With the Trustworthy Computing initiative, Microsoft has changed its approach: Now developers will engineer every product for security first, and if they need to cut or hide features to maintain product security, so be it. The first major software release that will embrace this new (for Microsoft) philosophy is Win.NET Server 2003.

Win.NET Server 2003 is, at heart, an upgraded version of Win2K Server, so how much true architectural work developers did to improve security is unclear. At a Win.NET Server 2003 technical reviewer's workshop earlier this summer, Microsoft Corporate Vice President of Windows .NET Server 2003 Management Bill Veghte provided a nifty sound bite: "Win.NET Server is secure by design, by default, and in deployment." If only everything I write about could be summed up so succinctly.

Secure by Design
At its heart, Win.NET Server 2003 uses a standards-based security model with technologies such as Kerberos authentication and public key infrastructure (PKI), IP Security (IPSec), and an intriguing new smart card-usage model that I think many administrators will adopt. Under this model, administrators log on with user-level accounts, swipe a smart card, and enter an associated password to access management tools and other high-privileged services and applications. Smart.

Win.NET Server 2003 also includes the new Secure Windows Update (aka AutoUpdate), which lets you download and install crucial software updates without any user interaction. This feature is even more important on servers than it is with interactive desktop systems such as XP.

And, of course, Win.NET Server 2003 includes the .NET Common Language Runtime (CLR), a run-time environment with stricter security rules than the underlying OS. We'll have to see whether this feature will drive enterprises in search of better security to .NET.

Secure by Default
Win.NET Server 2003 significantly reduces the default "attack surface" by disabling Microsoft Internet Information Services (IIS) and more than 20 other services that the OS used to install and enable by default. Other services, such as NetworkService and LocalService, now run with reduced privileges. And blank password-based attacks are no longer possible because Win.NET Server 2003 machines running with blank passwords can no longer provide network authentication. Frankly, I think the company should have bitten the bullet and not permitted blank passwords at all, but Microsoft told me that some environments demand this "feature."

If you choose to install IIS, the software defaults to running in a reduced functionality mode and can only serve static Web pages. When you turn on features such as the ability to serve dynamic Web pages using Active Server Pages (ASP) or ASP .NET, IIS will warn you about the ramifications of your decision.

Secure in Deployment
To reduce malicious code attacks, an exciting new feature called Software Restriction Policies (SRP) lets administrators specify which applications can and can't run on domain PCs. This change is important. You can specify that users can't install or launch certain applications, or you can simply provide a list of acceptable applications for locked-down desktops and specify that all other applications are off-limits.

Is It Really Secure?
Looking forward, the proof of whether Microsoft's work with Win.NET Server 2003 security has paid off will come in a year or so when we'll know how the OS has fared in the real world. If the past is any indication, Microsoft has a lot of work to do, and hackers will likely find a way around many of the security roadblocks that Microsoft erects. Is Win.NET Server 2003 more secure than Win2K Server? Absolutely. But whether Win.NET Server 2003 can meet the security challenges of the near future is a story for a distant day.

If you want to know more and live in or near New York City, Chicago, Denver, or San Francisco, you might be interested in our mid-October Windows Security RoadShow, where Mark Minasi and I will talk about Windows security. Mark's talk focuses on real-world security tips and tricks that will benefit enterprises today; I'll be discussing future security improvements in XP SP1, Win.NET Server 2003, and the nebulous and mysterious Palladium. For more information, check out the RoadShow Web site.
http://www.winnetmag.com/roadshows