Virtual machines aren't really more secure
I've been at several recent conferences where virtual machine (VM) and security “experts” were telling audiences how VM technology can be used to improvecomputer security. Wow! They are either drunk on the marketing Kool-Aid, misinformed, or simply trying to misrepresent VM capabilities to sell more product.
VM technologies are very cool, and great at saving money (and space, electricity, and more), but in all but a small minority of cases, they will not improve your overall security posture. Most of the time, using VM technology will increase overall risk. In a large percentage of the cases I've been involved with, clients treat VMs as something less than their physical machines, tolerating slower and poorer security policies than they would on real computers . They often use weaker passwords, take longer to patch, and allow operational practices (such as connections from high-risk to low-risk assets, unmanaged shares, missing security software, and overly promiscuous permissions) that wouldn't pass muster in their normal production environments.
Let's suppose the VM-using-client practices the same security practices and policies on their virtual machines as they do their physical machines. This is definitely a step in the right direction, and theoretically they should have the same security risk, right? No.
By their very nature, VMs have the same security risks as physical computers (their ability to closely mimic a real computer is why we run them in the first place), plus they have additional guest-to-guest and guest-to-host security risks. Security assessments against multiple virtual machine technologies have revealed multiple vulnerabilities in these areas, and practically, these risks will always be there. You can minimize them over a period of time using SDL (Security Development Lifecycle) practices, but the risks themselves will always be there. They're inherent in the model.
Most of the published VM vulnerabilities during the past year or so were incurred because the VM vendor added new VM features (such as host-to-guest drive mappings, VM-specific tools, and so forth) that allowed an attacker to jump from guest-to-host or guest-to-guest. But some of the vulnerabilities occur in the VM software layer without the additional features needed.
Some VM vendors are working on future technologies that they claim will improve the security of VMs, and perhaps they will. One is a new API, VMware's Vsafe, which will allow host or network security defense tools to analyze and defend VM resources (memory and virtual hard drives, for example). Another vendor is working on a sort of virtual intrusion detection system for guest-to-host attacks. Both of these ideas sound interesting, and are likely to improve VM security (though they still do not lower risk compared to physical computers ). But it is also possible that these mechanisms, which function in the host or hypervisor layer, will give way to additional guest-to-host vulnerabilities. Even if we decide that these technologies present no additional risk (which isn't realistic) to VM deployments, it means that we are still at a break-even point. They didn't improve overall security.
Of course, if you follow strong VM security practices you can minimize the risk. Good VM security practices include:
• Treat and secure your VM sessions as thoroughly as you do each physical machine under your control, or even consider stronger controls
• Make sure to keep your VM software patched
• Minimize the guest-to-host connections and tools (if it ain't needed, don't install)
• Make sure low value, high-risk guest sessions are not running on the same host as high-value guest sessions ( e.g. don't run a public Web server on the same host as your internal PKI server)
• Take VM vendors security attestations with a grain of salt
I remember sitting in Blackhat last year and hearing from a senior VM developer about the inherent risks involved in using a hypervisor, all of which are challenging for any VM vendor to solve. This is a great discussion on the benefits of a hypervisor layer, along with the inherent risks and challenges. Pay special attention to slides 13-19. Slide 15 is what led me to questioning "we improve security" VM vendors more. The same presenter has added on to his comments. He is painting both sides of the story and treating us like adults.
I think the developers at any VM vendor know the security risks they are coding against, but those risks aren't shared with marketing. Hold your VM vendor accountable to speak about security risks in a reasonable manner. One vendor was publicly embarrassed a few weeks ago for making unrealistic security claims.
Now, there is a possibility that VMs can improve your overall security. First, if a VM is significantly more secure than your physical box, then there is a chance that your overall session security might be improved. Although if your host is insecure, it's a hard argument to sell that something running on it can stay more secure.
Second, VMs allow you to minimize the number of physical boxes to manage. If minimizing the number of computers to secure is easier and more thoroughly done by your limited staff than it would be with more physical computers, perhaps your security risk will actually decrease. But to be honest, I've yet to see that scenario in real life. Most of the customers I've seen actually end up with lax practices and worse security.
Posted by Roger Grimes on April 18, 2008 03:00 AM
Posts
No comments:
Post a Comment