Whodunit: A Hyper-V failure may reveal fabled 'escape attack'

New Hyper-V and SharePoint hacks mean you need to revisit your virtualization security

Page 2 of 2

Key steps to reducing virtualization security risks
This hack should make everyone with virtualized systems question whether they are doing everything they can to ensure they are secure. To help you do that, I've put together a preventative checklist, including items that can apply specifically to Hyper-V:

  • Use Server Core for your Hyper-V parent. Server Core is a minimalist OS that reduces the attack surface and potential exploits. Fewer patches and updates are needed for Server Core, and you manage the server remotely using your Hyper-V management tools rather than directly on the server.
  • Do not run applications on a Hyper-V parent. Applications are for your child VMs, not the parent. I cannot tell you how often I see this rule ignored by admins who want to use that parent as a normal server. It already has a job, and it should do only that job.
  • Do not give admins who work with child VMs the same permissions as on the parent. This is common sense, but what if you're the same admin for both? In that case, you should have two separate accounts: one account for the child VMs and one for the parent. In security circles you hear the principle of least privilege preached all the time. This principle applies no matter what the platform, even if the execution methods differ. For example, EMC VMware's ESX has roles that can be used to give different levels of security.
  • Update all VMs regularly. VMs are no different than physical servers in that they need to be updated and patched. In fact, you should update and patch your VMs before you even turn them on. For Hyper-V, Microsoft has a tool called the Virtual Machine Servicing Tool (VMST) 3.0 that can do this, which helps avoid introducing vulnerabilities into your environment. You can also use tools like System Center Configuration Management to assist with patch management. If you use ESX, it has its own tools, as well as third-party ones.
  • Use a separate NIC for your VMs and parent. I found this recommendation on Microsoft's TechNet community. It says, "by default, NIC0 is for the parent partition. Use this for management of the Hyper-V server and don't expose it to untrusted network traffic. Don't allow any VM to use this NIC. Use one or more different dedicated NICs for VM networking."

There are plenty of other security practices to keep in mind, some of which are specific to the vendor you choose for virtualization. For example, ESX provides a built-in firewall whose configuration you should double-check. Regardless of the vendor whose products you use, most of your VMs will run some form of the Windows OS, so you need to make sure your security-hardening process takes into consideration every angle, including the OSes and applications running on those VMs.

This story, "Whodunit: A Hyper-V failure may reveal fabled 'escape attack'," was originally published at InfoWorld.com. Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 Page 2