VM Subnet
I started my planning at the lowest level of isolation: the virtual network. Although I could have physically isolated the network, for simplicity I placed the VMs on their own subnet. The solution wasn't perfect, but at least the unique IP addresses would help me configure the firewall, routers, and intrusion detection systems to treat the VM subnet differently. By having a unique subnet for the VMs, I could easily identify any problems originating from those machines. Best of all, I knew I could enforce strict firewall rules that could limit security problems without affecting Web browsing.
I went with a 10.1.0.0/16 network for use with the VMs, because the company used the 192.168.0.0/16 subnet for its main network. I dedicated a router port to that subnet and carefully built firewall rules to limit network communications from the VMs.
Because the VMs shared the physical network adaptors with the host machines, I needed a DHCP server that would give IP addresses only to the VMs. VMware has a DHCP feature for guest OSs, but from the main router I wouldn't be able to distinguish VM traffic from the host's traffic. Since I was already planning to use IPsec, my solution was to configure a DHCP server that could only communicate with other systems authenticated via IPsec.
As for my decision to use IPsec, I knew it might conflict with the requirement of low administrative overhead. After analyzing the risks, I decided to use IPsec authenticating with a shared key, which would achieve the isolation I needed but wouldn't require implementing a public key infrastructure. (For information on configuring IPsec, see "Using IP Security Policies to Restrict Access to a Server," March 2005, InstantDoc ID 45217; for information on using IPsec for domain isolation, see the Microsoft article "Server and Domain Isolation" at http://www.microsoft.com/technet/itsolutions/network/sdiso/default.mspx.)
Browser Configuration
A big part of the project involved configuring browsers so that users felt unobstructed even though we maintained some level of security. The most obvious solution was to relax some of the security settings so that IE was less restrictive about such tasks as installing Java or downloading and running an ActiveX component.
To achieve this balance, I had to adjust the default zone policies. Rather than blocking components and disabling scripting, I adjusted the settings to prompt before taking these actions. However, it didn't take long for me to realize that users would experience a lot of annoying prompts, even when browsing the most common Web sites.
Consequently, I stepped back and monitored a handful of users as they used the Internet. Most users had developed some kind of workaround to cope with security restrictions— either using Mozilla Firefox or Opera to access some sites or adding sites to the trusted-sites list in IE. But every user was quick to point out one or two sites that didn't work no matter what. This scenario often arose when a Web site that was in the Trusted Sites zone tried to download a component— such as Java—from a Web site in a restricted zone.
I noticed that users didn't need unrestricted Internet access—they just needed a few basic components to be able to work with a variety of Web sites. Furthermore, the components they needed were quite common and widely accepted as safe to install: Adobe Acrobat, Adobe Shock-Wave Player, Macromedia Flash, and Apple QuickTime, among others.
It occurred to me that I didn't have to significantly change security policies—I could simply preinstall the most common components to give the appearance that I'd removed security restrictions. In fact, I could probably increase security while giving users the illusion that I had relaxed it. After all, it wasn't the security restrictions that users disliked; they just needed Web sites to work. I could preinstall the most common components and prepopulate the trusted-sites list with the most commonly visited sites. Doing these two things would give users the compatibility they needed while making it less likely that they'd encounter a new component that needed to be installed, and I wouldn't have to completely remove the restrictions on ActiveX components.
To enable all sites to use these components, I configured Group Policy to let users install ActiveX components, but only those that were on the preapproved list. I manually compiled the list of components shown in Table 1 by looking at the components installed on various systems. I then installed the components as administratorapproved components using the Profile Manager tool from the Internet Explorer Administration Kit (IEAK) 6 SP1.
Populated Zones
Populating the trusted-sites list was a bit complicated. Everyone visited common Web sites, but to avoid compatibility problems, I wanted the list of sites to be comprehensive. To generate the list, I used Microsoft's free Log Parser utility.
I started by writing a query to pull the current trusted-sites list from a dozen systems on the network that together closely reflected overall network usage. On each system, I ran the following Log Parser command (which must be typed all on one line):
C:\>logparser "SELECT DISTINCT
EXTRACT_TOKEN(Path, 8, '\\')
As Domain INTO
TrustedSites-
%COMPUTERNAME%.txt
FROM 'HKCU\Software\Microsoft\
Windows\CurrentVersion\
Internet Settings\ZoneMap\
EscDomains'
WHERE ValueName LIKE
'http%' " -o:NAT -rtp:-1
-headers:off
This query extracts domain names from the list of hosts in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings\ZoneMap\EscDomains registry key and saves the list of names to a text file in the current directory.
Register
