Hyper V is a popular hypervisor that comes built into all Windows systems. Because it is so widely deployed, it has also gained the attention of hackers, and Hyper V security issues are a primary concern for organizations running Microsoft virtualization. This article will explain the challenges of incident response in a virtualized environment, and provide specific best practices that can help you address Hyper V security risks.
What Is Hyper V?
Microsoft Hyper V is Microsoft's hypervisor for hardware virtualization. It is a low cost alternative to VMware virtualization. Hyper V lets you build and run a virtual machine (VM) - a software-based computer infrastructure. VMs can provide all the functionalities of an actual computer, including running programs and an operating system.
The advantage of using virtual machines is their flexibility, letting you reduce costs and save time when your computing resource needs change. Virtualization is often more efficient than relying on physical hardware to run an operating system.
With Hyper V, each virtual machine runs in an isolated space, allowing you to run multiple VMs simultaneously on the same hardware. You may use multiple VMs to isolate your workloads and prevent issues affecting one workload from spreading to others. VMs also let you provide different access levels (i.e., to different systems) to each user and service.
Unique Response Challenges in a Virtualized Environment
Virtualization offers advantages such as greater flexibility, but it can also make it harder for organizations to respond to suspicious user or device behavior that may indicate an attack. This is one of the fundamental challenges in cloud security, because cloud environments are based on hypervisor virtualization.
Security challenges affecting virtualized environments include:
- Data visibility - different VMs managed by a single hypervisor instance can share information without sending it to the physical network.
- Insufficient isolation - there is no strong default separation between partitions, so you might need to implement changes to the documentation.
- **Changing virtualization environment - **usually, you move VMs manually or automatically to react to resource or workload changes.
- Limited access to inter-partition pathways - it may be difficult to physically access the pathways between partitions from outside the host.
- Slower response - certain capabilities, such as direct access memory, might make it harder to move entire partitions from compromised platforms to recovery hosts quickly.
- Trust levels - servers with varying levels of trust on a single host are easy to mix.
Ensuring Effective Incident Response for Hyper V
To ensure Hyper V workloads are secure and effectively respond to security incidents, you should consider the following techniques and features.
Maintain Visibility and Introspection
Monitoring tools need to have visibility over internal packets in different virtual machines managed by a single hypervisor. The ability to view internal VM pathways is called introspection. In addition to monitoring anomalous packets that pass between different physical servers, you should monitor anomalous packets passing through multiple VMs on a host. Traditional security tools like firewalls cannot see inside virtual spaces.
Hypervisor solutions typically provide tools to support introspection into the pathways between virtual machines, but these rarely come in the form of full implementation. If you don't integrate these tools with your existing monitoring system, you may have to manage different rule sets. You should also integrate VMs into a unified log management system.
Group Your Virtual Machines
Virtualization lets you place a server on whichever host is available, helping to maximize resources, but it can also make security more complex and costly. For example, a VM that processes sensitive data requires stricter controls than a VM that handles less sensitive data. If you spread sensitive machines across multiple hosts, you need to apply the relevant controls to each host.
You should classify data according to sensitivity and manage your VMs based on the data they contain - this lets you place all sensitive VMs on a restricted host (or small set of hosts). Avoid mixing VMs that process sensitive and non-sensitive data. Grouping your VMs based on data classification enhances security and minimizes complexity and costs.
Separate VM groups also help you adjust your incident management processes without significantly increasing your budget.
Isolate Hyper V Traffic Using a Secure Network
To keep your traffic secure, you need to understand which traffic must not traverse user networks. You should isolate sensitive traffic, restricting it to dedicated virtual or physical network segments.
Examples of sensitive traffic include cluster and replication traffic, server backbone traffic, and communications between Hyper V hosts and storage arrays. You should encrypt such traffic wherever possible. Hyper V offers native options for encrypting migration traffic and VM state, although you might want to use encryption protocols like IPsec.
Protect Virtual Machines Using Guarded Fabric
Rogue administrators are a major risk to virtualized servers. Rogue admins can copy VMs to a removable media device, delete the originals, and run the VMs on unauthorized hosts. You can leverage the Hyper V guarded fabric to protect against VM leakage like this. A VM protected by guarded fabric is known as a shielded VM.
Shielded VMs are virtual machines encrypted with BitLocker and only run on authorized Hyper V hosts. Guarded fabric infrastructure lets you encrypt shielded VMs and determine which hosts are authorized to run them. Guarded fabric encompasses Microsoft's Host Guardian Service (HGS), which you can run in highly available configurations such as multiple shielded VMs and guarded Hyper V hosts.
Gen 2 VMs can run on Windows Server 2012 Hyper V or later and support VM shielding, while HGS only runs on Windows Server 2016 or later. With Windows Server 2019, Microsoft introduced Linux VM support and an offline feature. The offline mode ensures that shielded VMs continue functioning if they lose connectivity to HGS.
Seize Compromised Virtual Servers
If a server is compromised (or a criminal used it), you may need to seize it to enable forensic analysis. It might be difficult to retain RAM content for evidentiary purposes. If, for example, you remove power from a physical server to mitigate the impact of a breach on your business, you might also cut off potential clues that forensics can analyze. You don't have to lose the attacker's footprints with virtualized servers.
Microsoft Hyper V offers a snapshot capability that lets you capture point-in-time images of VMs. These VM snapshots enable the creation of encapsulated server copies that preserve the conditions at the time of the breach and help inform the investigation. You can create a rich environment for forensics by recovering compromised VMs to a quarantined hardware replica.
However, you may require more than a suspension file or snapshot - you should collect all files used by your VMs when you implement your evidence strategy.
You should suspend VMs in cases where fast isolation is unnecessary or impractical. If you shut down a VM altogether, you cannot guarantee the preservation of volatile storage like RAM. Depending on your configurations, suspension can preserve evidence for forensics purposes.
Conclusion
In this article I explained the basics of Hyper V and security for virtualized workloads, and covered the following best practices that can help you secure and respond to incidents on Hyper V virtual machines:
- Maintain visibility via monitoring solutions
- Group virtual machines on hosts based on their sensitivity
- Isolate Hyper V traffic via secure networking
- Leverage BitLocker and Microsoft's Host Guardian Service (HGS)
- Create snapshots and perform forensic investigation of compromised VMs
I hope this will be useful as you improve your security controls for your virtualized workloads.