Security Insights from Microsoft Security Architect

Last night I attended the northern Virginia ISSA monthly meeting. The guest speaker was Dean Iacovelli, Security Systems Architect for the Microsoft Mid-Atlantic district. His overall theme was "beyond patching." Dean supports over 200 enterprise customers, for which he serves as "security pinata." Several ISSA members took him to task for Microsoft's security failings, but I thought Dean was diplomatic and handled their mildly aggressive questions well.

Dean said that the patching approach to security is becoming a "second or third line defense, like backups. You patch regularly but hope you don't need them." As evidence he cited the decreasing window of time between announcement of a vulnerability and release of an exploit. Patches are still the best way to fix a vulnerability in broken software, so Microsoft has been pursing multiple initiatives to improve their patches.

First, Microsoft is migrating from multiple update sites (e.g., Office Update, Windows Update, and Microsoft Update Center) to a single future "Microsoft Update" site in late 2005.

Second, Microsoft realized their seven profit and loss centers support eight different software installation methods. This year they will move all software installation to two methods. Operating systems will use update.exe and applications will use MSI 3.0. This will make using Microsoft Baseline Security Analyzer, Microsoft Systems Management Server, and Microsoft Software Update Services (migrating to Windows Update Services) more predictable and effective.

Third, Microsoft has worked to make their patches better. They have a standardized naming convention to ease management. They use binary diffs to reduce patch size. They are also "actually inspecting system configuration" (as opposed to pretending to do so?) to determine what patches are really needed.

Dean next discussed Security Configuration Wizard. This seemed like a fairly impressive way to lock down systems. It automatically detects and configures Microsoft services and their options, Microsoft client applications and their options, third-party applications, IPSec policies, registry settings, audit features, and IIS. Essentially you can apply all of Microsoft's recommended configuration options via an automated tool. I was disappointed to see Dean's demo fail, but I see the promise of the technology.

Dean mentioned a related tool called Microsoft Application Compatibility Analyzer. The idea behind this program is to run it for a week or so on a host to determine what applications users employ. This helps administrators learn if XPSP2 will break any of the user's applications. I hope to see more of this sort of tool for future Windows upgrades.

Speaking of XPSP2, Dean gave a behind-the-scenes look at the reasons for its development. Apparently the Blaster worm had a huge effect on Microsoft. They "took almost all developers off Longhorn for a year to work on XPSP2." The theme of XPSP2 was applying good default configurations. For example, XPSP2 enables the Microsoft firewall by default. It denies inbound connections to help prevent intrusions. XPSP2 also denies null sessions by default. Dean said XPSP2 has been downloaded 150 million times.

One of the ISSA attendees complained that XPSP2 features were not available for Windows 2000. In fact, Dean said Internet Explorer 7.0 will only be available for XPSP2 (at least at present). The ISSA attendee said it was too expensive for customers to upgrade to XP. I wanted to say that the best update to Windows 2000 is Windows XP, but I kept quiet. Dean replied to the other ISSA attendee that most big Microsoft customers with Windows 2000 installations "already own Windows XP" by virtue of their Microsoft Enterprise Agreement. He said getting these customers to upgrade to Windows XP is one of Microsoft's biggest problems.

Dean pitched four efforts Microsoft sees as being "beyond patching." Since he spent so much time on the earlier issues, Dean had to briefly describe each. The four efforts are:

1. Isolation and resiliency
2. Network segmentation
3. Rights Management Services
4. Smart cards for remote access

I found his network segmentation discussion interesting. Microsoft is pushing for an all-IPSec internal network. All Active Directory-managed hosts would speak IPSec, and anything that doesn't is considered untrusted. I believe Dean said this is how Microsoft operates its internal network.

Regarding Microsoft's internal practices, Dean encouraged listeners to visit the IT Showcase site. There Microsoft publishers papers on how it secures its own network. He said that Microsoft operates the largest wireless 802.1x deployment in the world. They have also run Network Access Protection for two years for VPN clients.

I found Dean's short description of Rights Management Services to be intriguing. It will use eXtensible rights Markup Language and AES 128 encryption to protect individual documents. Only those operating rights management-enabled programs should be able to read RM-protected documents. I welcome the idea of a data-centric approach to security, but I am sure someone will figure out how to break this system.

Beyond the four efforts already in production, Dean pointed to three future area for Microsoft:

1. Network quarantine
2. Vulnerability assessment
3. Active protection

First, Microsoft Network Access Protection will work with Cisco Network Admission Control. Initially they did not want to cooperate, but their alliance was a result of customer pressure. Network Magazine profiled the two technologies recently. At first glance I prefer Cisco's 802.1x switch port-centric approach, rather than Microsoft's DHCP-centric method. Who cares if I don't get a DHCP server to provide an IP, when I can steal what I need from another host?

Dean's quarantine slide said NAP is "not designed to protect against malicious users." Somehow I think the Microsoft marketing drones will end up twisting NAP to be useful against malicious users. Again referring to Blaster, Dean said 70% of his customer's compromises were caused by VPN users, and 30% by "walk-ins." Microsoft believes that if NAP can quarantine these sorts of users, then it will help contain future Blaster-like problems.

The second step, vulnerability assessment, is code named the "Geneva feature set." Microsoft seems to want to offer continuous internal vulnerability assessment services. These will make further inroads to the security space, given Microsoft's Malicious Software Removal Tool, Microsoft AntiSpyware, and SpyNet. I didn't really hear much about the third step, code-named Mako.

All of these are slated for Longhorn, due some time in 2007. He said a beta should be available by Q4 2005. However, Microsoft now says "it's ready when it's ready." Customers will need to do a lot of testing for these features, especially network quarantine. Dean recommended the following processes need to be considered: rollout and change process control planning; success matrices and measures; exemption analysis; host health modeling; health policy zones; secure network infrastructure analysis; RADIUS implementation; and zone enforcement selection. What does all of this mean? Figuring it out is probably the first step!

One of my responses to this was to consider the complexity of all of the steps Microsoft is taking to implement security for hosts running Windows. With complexity comes opportunity for misconfiguration, plus vulnerabilities introduced by new code and processes. Microsoft might say their new systems will prevent rogue insiders or malicious outsiders from attacking Microsoft services. It seems to me that the opportunity to attack the authentication and encryption services still exists. Why bother to fool, bribe, or otherwise subvert a guard if you can silently kill him?

I had a similar thought with respect to the IPSec-everywhere approach. This will help preserve confidentiality and integrity within the enterprise. However, most internal intruders are probably rogue insiders. They will already have the authorization needed to access internal documents. Independent network-based systems trying to audit internal activity will be blind to IPSec-encrypted traffic. Is this trade-off worth it? I'm not sure.

As an aside, Dean mentioned a Windows feature of which I was unaware: Server Message Block signing. I plan to look more closely at this.

I find these ISSA meetings very useful and I plan to join my local chapter.