Keeping malware from infecting networks is a never-ending battle. Over the past few years, the IT world has made great progress in maintaining acceptable network defenses, although sometimes at the expense of usability and compatibility. For one company, that was too great a price to pay. Here's how I lowered the usability cost of malware prevention for one of my clients while maintaining security.
The Situation
Recently, a company hired me as a security consultant. Due to the nature of my client's business, employees spend a lot of time on many different Web sites. The company encourages employees to use their computers to play, to communicate with others, and to do whatever else is needed to foster creativity. Its problem was that ever since the release of Windows Server 2003 Service Pack 1 (SP1) and XP SP2, employees couldn't get the Web sites they visited to work properly.
Support incidents piled up as employees requested help to install ActiveX components, troubleshoot zone issues, enable pop-ups, and adjust cookie settings—whatever it took to get Web sites to work.
Sometimes users went ahead and eased security settings themselves. This relaxed security had consequences: Despite taking such basic precautions as using firewalls, email virus scanning, and automatic updates, the company still experienced an increase in spyware, viruses, and other malware-related incidents.
However, my job wasn't to harden Windows, but rather to relax some of the company's OS security defaults to improve usability while sacrificing as little security as possible. The company set some guidelines for my solution: It had to be simple and not require a major network overhaul, and it couldn't add significant administrative training or overhead. In short, the company wanted something I could easily attach to the existing network infrastructure.
I explained the risks involved with relaxing security restrictions on Web browsers and other software. For example, a user might visit a Web site that exploited some unpatched vulnerability in Microsoft Internet Explorer (IE) to install a keylogger on the user's system, giving the attacker access to everything the user typed on the keyboard. From that point on, user's passwords and just about any sensitive information typed would be at risk—it happens all the time. Or a user might inadvertently install spyware that significantly slowed the system or made it unusable.
I proposed my standard Windows lockdown procedure, but management quickly shot that down. The company wanted me to relax security just enough to get everything working but without affecting usability—it wanted to fully use the Internet without being vulnerable to it.
As I walked through the office, I caught a glimpse of the challenge before me: I saw IM windows open on many desktops, elaborate custom desktop themes, system trays loaded with icons, and USB hubs connecting devices of all varieties. One thing was clear: These were highly skilled, creative users whose work lives were centered on their PC. One executive told me he wished he could just have two separate networks: a safe one for work and a compatible one for Internet access. Turns out he was on to something.
Virtual Solution
I contemplated the idea of having two separate networks. We all knew that building two separate networks simply wasn't practical, but the idea intrigued me—there are plenty of ways to isolate networks on a single connection. My first thought was to experiment with a virtual test network using virtual machines (VMs)—something I do all the time for research and testing.
Then I realized that my test-network idea itself was the solution. I could quickly build an entire parallel network made up of VMs that could easily accommodate any level of isolation.
The virtual network would initially coexist with the main network, but I would use virtualization technology to direct that network's traffic to VMs running on each desktop. We could achieve reasonably good isolation of the VMs by assigning IP addresses from a separate subnet and using IPsec to secure the traffic on the main network. Although this approach wouldn't stop a malicious hacker from specifically targeting the main network, it would work well for isolating malware threats.
A big bonus of using VMs was that if users at any time felt their system security was compromised or otherwise unstable, they could revert to a clean master image in a matter of seconds. Users could play with—or destroy—VMs to their heart's content without threatening the stability of their work system.
Of course, no company, product, or technology can guarantee total security. If someone has hacked the VM to the extent that they can access the host, you probably have bigger concerns anyway.
The point with this solution was to add a pretty good layer of isolation. The goal was to balance risk and usability and to isolate the risk to minimize the effect on the company's network. Furthermore, we would have a method to quickly identify and recover from security incidents.