Security in a Virtual World

**Security Viewpoint – September 2008
**See other Security Viewpoint columns

By Kai Axford, Senior Security Strategist, Microsoft Trustworthy Computing Group

- - - - - - - - - - - - - - - - - -

What is Virtual Security?

Before I begin to discuss the concept of virtualization security, I want to set some expectations. Virtualization security is not about getting your T6 Epic gear in World of Warcraft or buying an island fortress with Linden dollars in Second Life.While these are good examples of “virtual world” security, it’s not really what I want to talk about.  

Unless you’ve been heads down in the server room for the past few years, the buzz in the IT business is all about this new concept called “virtualization.” How big is this new market? According to reports from IDC in March 2007, “The number of virtual servers will rise to more than 1.7 million physical servers by 2010, resulting in 7.9 million logical servers. Virtualized servers will represent 14.6% of all physical servers in 2010 compared to just 4.5% in 2005.” As with any new market, vendors rush to invest in the opportunity. We see vendors such as EMC, Citrix, and Microsoft getting involved. Microsoft got in the game a few years ago with our Virtual PC and Virtual Server products, and more recently with the newly released Hyper-V™ hypervisor-based virtualization technology that is a feature of the Windows Server® 2008 operating system. Like it or not, virtualization is here to stay. If that’s the case, and it is, you better be ready to secure it.

I also want everyone to understand that what I’m talking about here is really focused on “server virtualization” and not about presentation virtualization (e.g. Terminal Services) or application virtualization (e.g. SoftGrid). All good stuff, but far outside what I can cover in this brief space.

As with any new technology, there are plenty of myths out there with regards to protecting it. I’ll address the Top 3 Virtual Security Myths, and then close with a few considerations if you’re making a decision to go the virtual route.

Myth #1: “I only have to patch my host OS / Kernel.”

Let’s address this myth right away! You need to retrain your brain and start thinking of the virtual machine (VM) as an actual physical asset. We need to look at these VMs as a machine on the network would view them. Are your users going to settle for “We lost the customer database, but it was only a VM” excuse? No. That means we need to have an update procedure in place, we need to run antivirus inside our VM, and we need to set up proper restrictions on permissions and any kind of domain isolation as well. Yes, you need to keep those boxes up-to-date and you need to schedule maintenance windows to accomplish those operational tasks. Will it take more time? Not any more time than it would to patch… er… ”update”… any other physical servers. I’ve talked to many of you in my travels and I’m amazed by how many folks just seem to forget about updating the VM. Myth busted.

Myth #2: “If I just protect my host machine, it will protect my VMs.”

This one is both true and false. We need to expand the “range of protection” outside the host machine. Consider the many attack vectors that exist when we’re talking about virtualization security. We have host hardware, the host OS, the VM hard disk files, the VM configuration files, remote management utilities, the VM OS, and, of course, the virtual network it all runs on. If you take a look at the VM configuration file in Figure 1, you can see the bad things that can happen if people get access to those virtual hard drive (VHD) configuration files on the host and start changing paths. 

Figure 1. Bad news: An example of VHD redirection by altering the configuration file

While I’m on the topic of protecting the host, let me address some of the attacks that have been getting a lot of press. I’m talking about the “virtual rootkits” like BluePill, Vitriol, SubVirt, and whatever other malware is cool with the kids these days. These attacks present no more danger to you than any other form of malware. Some have made claims as to the “invisibility” of these types of attacks, but as with all malware, it’s only invisible until someone finds it and writes an antivirus signature for it. If it were me, I’d be more concerned with someone coming in and throwing the Time Synch off between my host and guest machines. Think about what happens if I roll the date and time forward or backward on your domain controllers. Think about the impact it’d have on your public key infrastructure (PKI) and all those certificate revocation lists (CRLs) and certificates!As I always say, protect yourself from the things that present the greatest risk… unless you have an unlimited budget. 

Almost every VM solution I’ve seen provides some sort of remote management utility. For Microsoft, I’d recommend the Microsoft® Remote Server Administration Tools (RSAT) for Windows Vista®, the Hyper-V Management Console in Windows Server 2008, and Microsoft System Center Virtual Machine Manager 2008 (Virtual Machine Manager 2008 will allow you to connect to any of the VMWare’s ESX servers you have in your infrastructure)! But this is an article on security, not management. So, you’re asking: “How do I protect myself from the threat these remote tools may present?” You do it by using a principle we’re all familiar with: “The Concept of Least Privilege.” Who has access to the tool and what permissions does that person have on remote servers, whether physical or virtual? Am I implementing limited-use accounts on the controls? Is the connection from my machine to the remote virtual machine done over an encrypted connection? Finally, am I auditing and logging the activities of the remote session?

When we talk about ways of mitigating risk on the host machine, we’re simply talking about hardening the host (which I hope you’ve already done). That means reducing the attack surface. And, running without the overhead of additional “virtualization applications” such as Virtual PC helps considerably. Try running on a platform that uses a hypervisor, such as Windows Server 2008 with Hyper-V. The advantages of running with a hypervisor are significant. For instance, each VM spawns a dedicated VM worker process. This way, if VM #1 decides to die, that VM and only that VM is affected, and VM#2 keeps chugging along. Talk about uptime! If you’re running Windows Server 2008, consider running your VMs with a Server Core installation whenever possible. Server Core removes a lot of the extras in Windows Server that you’re VMs won’t use, and, since you’re going to stuff the machine in a dark corner of the server room and connect remotely, who cares if there’s a graphical user interface (GUI)? Less attack surface is good.

Figure 2. Running your VM in a Server Core role reduces the attack surface

If you’re using Windows Server 2008 Hyper-V to run your VMs, then think about implementing some powerful security technology you’ve already bought and paid for: BitLocker™ Drive Encryption. BitLocker provides full volume encryption of all volumes on the drive… that’s right: all volumes. You now have the ability to encrypt not only system partitions, but data partitions as well—all from the GUI. It will also help with another area of security we often overlook: physical security. Multiple servers on a single box means that instead of stealing multiple servers, I only have to steal the VM Host. BitLocker Drive Encryption safeguards those physical drives if your server is ever…missing.

Lastly, we should always do simple things, such as using access control lists (ACLs) to enforce permissions; auditing file access, file creation, file deletion; and, finally, making backups and archiving in accordance with your disaster recovery (DR) plan.

Myth #3: “Virtual hard disk files are secure by default.”

Everything is secure until you or someone else touches it, right? The problem is that you never really know where that VM came from and, even if you built it yourself, you never know who touched it last. We pass VMs back and forth and that’s probably not a good thing. “Hey <insert fellow IT worker name here>, do you have a VM of Windows® XP I can use for a customer demo?” “Sure thing, here you go!” I’m pretty sure it’s not corrupted, but how do I know for sure? As I’ve already mentioned some of the biggest issues you’ll see out there are going to come from unpatched guest VMs. You can issue all the “corporate policy” you like. You can scan your network looking for violators, but if someone is just bringing up a VM on the local area network (LAN) to do a quick demo, test some code, or surf the net, they’re not typically going to wait for all the missing updates to install. Easier to just shut it off and do it later (which we all know means never). This is actually a pretty significant problem and one that’s not easily fixed. How do you catch a machine that is there one second and gone the next?

Another key problem around guest machines is seeing virtualization as the answer to the plea of “Please Please Please! Just help me find a way to keep my Windows NT® 3.1 Server alive for another millennium!” (Answer: You can’t. It’s 2008. Let it go. You’re running an OS that was released the same year as the movie Jurassic Park. It’s time to say goodbye to dinosaurs.) Too often we’re seeing older OSs being virtualized, even though they do not possess many of the typical built-in security functions we have today, and it does nothing but create risk for your environment.

Finally, take advantage of virtual LANs (VLANs) and other ways to segment the network to safeguard your guest machines. Hyper-V does a great job of separating the VMs from one another, even prohibiting VMs from talking to one another outside of normal networking channels. Each VM has its own unique memory address space, which prevents “leaking” from one VM to another. Remember, since we’re no longer thinking of these as “virtual machines” in our planning, we are free to implement solutions like IPSec Domain Isolation and even physical isolation, through the use of dedicated VM-specific physical network interface cards (NICs).

Virtualization: Save Money. Save Earth.

One of the key areas for Microsoft Trustworthy Computing is driving our Environmental Sustainability efforts. The amount of electricity required to power a data center is immense and costly. By moving to a model that allows multiple servers to run off a single physical machine, you’re actually using your electricity more efficiently. How nice will it be to say at the next budget meeting, “Since rolling out the new servers, we’ve increased productivity by 30 percent and reduced our fixed costs by 40 percent.” Your finance guys will love you. So will the planet.

Threat Landscape: The Risk of Virtualized Attackers

As with any great technologies, there are always those who will see ways to use it for malicious intent. Virtualization is no different. Virtualization vendors are typically concerned with safeguarding the VM from attack, and aren’t really thinking of criminals using VMs to launch attacks. One of the best things about my job is that I get to work closely with several law enforcement agencies around the world. They are starting to see criminals use VMs as a way to commit crimes, because they think VMs are untraceable. These criminals figure “If I can boot up a VM, launch my attack, and quickly shut it off and discard my changes to the original machine, I’ll never be caught.” Wrong. Pretty much every VM action gets written to the SysLog be default. Like any file, just because you “delete” it, doesn’t mean it’s gone to a forensics tool; the pointer has simply been removed. Also, we still have network traces from the IP address; audit logs that track who did what, when, and where; router logs; and, if you’re lucky, video surveillance of the corporate workplace.

Conclusion

I hope this has dispelled some of the myths you may have heard about virtualization security and has served as a primer for those of you considering moving to this new technology. In closing, I’d like you to remember the following key action items to help secure your virtual environments:

• Reduce the attack surface on the host.
• Always use least privilege access.
• Audit the deployment, maintenance, control, and access to VMs.
• Take advantage of backups, snapshots, and redundancy to reduce impact of host/guest maintenance.
• Secure your VM hard disk and configuration files, including backups and archives.
• Use virtual networks/VLANs/IPSec to isolate machines, especially before they are exposed to the network.

---------------------------------------------------------------------------------------------------------------------

**About the Author
**Kai Axford, Certified Information System Security Professional (CISSP), is a Senior Security Strategist with the Microsoft Trustworthy Computing Group. A nine-year Microsoft veteran, Kai is responsible for discussing and recommending security solutions to both private- and public-sector organizations. He is recently returning from a three-week tour of Canada, where he discussed virtualization security. Enjoy his other (mostly) security-related pontifications at Security Minded with Kai the Security Guy. Kai would like to thank Bruce Cowper, Chief Security Advisor for Microsoft Canada, for his assistance in this endeavor.