Re-thinking the security of virtual machines

Recently, I've heard many security officers talking about using virtual machines as a way to increase security. If your developers need local administrator rights and privileges and they can't have them on their normal PCs, just give them a VM. If an end-user needs to circumvent a few enterprise policy settings but can't get the management approval, give them an unmanaged VM. If people need to browse untrusted W

Recently, I've heard many security officers talking about using virtual machines as a way to increase security. If your developers need local administrator rights and privileges and they can't have them on their normal PCs, just give them a VM. If an end-user needs to circumvent a few enterprise policy settings but can't get the management approval, give them an unmanaged VM. If people need to browse untrusted Web sites, give them a VM they can easily reset. At least, these are the reasons I'm hearing why security-lessened VMs were created.

And here's what I want to communicate: If you allow the VM to be connected to your network and/or domain (specifically, if the VM has network capabilities), the VM probably increases your security risk -- it doesn't lessen it. Get it straight in your head and undo the bad conventional wisdom. Unless the VM is network-disconnected, you need to treat the VM machine just like you do a physical, real machine; or accept the increase in security risk.

By their very nature, virtual machines mimic nearly all the qualities of a working production OS. Every security threat -- and potentially more -- that you have with a real machine, you have with a virtual machine. The transient nature of virtual machines leads people to be more lax about their security.

First, virtual machines are less likely to be patched. How can the VM get patched, when it is constantly stopped, started, and reset? It can be done, but it takes more consistent effort. "Why patch it at all if I can just reset when it gets infected?", some users are surely thinking.

Second, users, and especially IT support people, tend to use weaker passwords in VMs than they use on real machines. Many of the VMs I come across have a password of password (or Password2 if complex passwords are required). Many VMs have blank admin passwords (which can actually be secure against unauthorized remote logons). But by far, the biggest problem I've seen is the reuse of passwords between the VM system and the user's production system.

Because the VM system is more likely to be weaker security-wise, reusing passwords is just asking for trouble. It's probably not as bad as reusing business passwords at home but not much. Think about it. If the VM has been intentionally set up to be more open and less secure, it needs stronger password policies, not weaker.

Third, virtual machines are more likely than traditional workstations to contain rogue software that the end-user doesn't want management to know about. I've found many VMs running password cracking and sniffing tools. The user places them in VMs that they have shutdown most of the time so that the typical nightly network scanning tools can't find their stray software and alert security folks.

Fourth, another big reason people have VMs is to visit untrusted Web sites, which they can quickly reset if they suspect malware has infected their session. The user's more risky behavior means they are more likely to come in contact with malware. Add to that the fact that the VM is less likely to be patched, and you have a malware writer's silent installation dream.

How many users will even recognize that their session was infected and reset the VM? If end-users were so good at recognizing when they got infected we wouldn't even need the VM in the first place.

How much more likely is it that VM users will not reset their VM sessions over longer and longer periods of time? And even if the user resets their VM image daily, malware can do all the damage it needs to do during the user's current session. Today's network bots are intentionally designed for short useful lives. They don't need 8 hours to search your network for available open shares, to steal passwords, or to send out millions of spam messages.

Finally, a VM can be weaker than a real PC because of the break-out-of-VM-to-the-underlying-host issues. There have been dozens of theoretical attacks, and a few real exploits, against VMs that allow attackers hitting the VM to access the underlying host machine. So, in this respect, VMs can actually be less secure than a real computer.

To clarify, if a VM is connected to your network and domain, and its security is lessened as compared to your normal production computers, it will increase the risk of malicious attack. For me, when someone suggests using a VM as the solution to some security problem, I think of the VM just like I would a real, physical PC. The same security risks are still relevant.

If the VM can be isolated from the network or doesn't have a network connection at all, then there are potential security benefits. There are also virtual environments that are specifically built to prevent malware infection, but I've yet to find the VM environment that worked perfectly to prevent malicious modification. There are ways to give certain groups of users more open environments, but I don't find that VMs are the answer most of the time.

Copyright © 2008 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)