Application Layer
Guest OS Layer
Virtual Machine
Manager
Kernel Layer
Hypervisor
Driver/Module
Layer
Hardware Layer
The Hypervisor
Diagram from Edward L. Haletky, The Virtualization Practice, LLC
Hypervisor schedules VMs
on each physical
Core/CPU/Hyperthread
Hypervisor Controls CPU
Complete control on how
Cores are assigned to vCPUs
CPU will be used for
hypervisor, virtual switches,
etc.
Understand Hypervisor Security: Access to CPU
Type-1 Virtualization
Type-2 Virtualization
Container Virtualization
The Virtualization Journey
Consolidate Resources
• Improved efficiency and utilization
of IT resources with simple
virtualization tools
Server
Storage
Increased Agility
Network
Consolidate
Manage Workloads
• Improved IT staff productivity with
integrated systems management
dashboard for physical and virtual
resources
Automate Processes
• Consistent and repeatable
processes based on best
practices, business priorities and
service level agreements with
simple virtualization tools
Resources
Manage
Workloads
Automate
Processes
Optimize
Delivery
10/04/10
Optimize Delivery
• Self provisioned by users based
on business imperatives,
unconstrained by physical
barriers or location.
7
VM Vulnerability Classes
VM Migration
Transfer from one physical
server to another, with
little or no downtime
For load balancing and
high availability
VMWare Vmotion brochure
VM Migration attack
If transfer is unencrypted, man-in-the-middle attack is
possible, allowing changes to the VM enroute.
John Oberheide et.al., Univ. of Mich.
Virtual network configuration
VMWare
Attacking the hypervisor
• Hyperjacking
– Installing a rogue hypervisor:
• One method is overwriting pagefiles on disk that contain
paged-out kernel code
• Force kernel to be paged out by allocating large amounts of
memory
• Find unused driver in page file and replace its dispatch
function with shellcode
• Take action to cause the driver to be executed
• Shellcode downloads the rest of the malware
• HOST OS is migrated to run in a VM
– Known tools SubVirt (Microsoft and U. Mich), BluePill
(Rutkowski), and others.
Security complexities raised by
virtualization
Complexities
• Dynamic relocation of VMs
Before Virtualization
• Increased infrastructure layers
to manage and protect
• Multiple operating systems and
applications per server
• Elimination of physical
boundaries between systems
• Manually tracking software and
configurations of VMs
• Maintenance of virtual images
• Image sprawl (proliferation)
• 1:1 ratio of OSs and
• Virtual appliances (Trojan Horse)
applications per server
• Public Cloud risks
After Virtualization
• 1:Many ratio of OSs and applications per server
• Additional layer to manage and secure
–“Black box” sharing in clouds
reduces visibility and control
–Privacy and accountability
regulations
From Ajay Dholakia, IBM
Virtualization security – Driving
Requirements
requirements
 Secure platforms & engineering process
 Threat and vulnerability management
–Internal / external threat mitigation
 Privileged access
–Role segregation & access control
 Data confidentiality and integrity
–Data @ rest ( storage ) data in transit (network)
 Regulatory compliance
 Multi-tenancy / isolation
–Isolation management of Virtual Servers
 Image / virtual appliance security
 Consolidated systems security
–Consolidated server, storage, net. security mgmt.
 Systems Integrity Management
–Trusted software / firmware / hardware
From Ajay Dholakia, IBM
Virtualization Security Summary
• Virtualized systems have added new vulnerabilities to
infrastructure
• Using virtualized systems doesn’t add much security,
since the same server connections are still needed
• Adding the hypervisor (OS) broadens the attack surface
• Additional complexity brings potential for new attacks
• Migrating VM’s complicates their security
• Some shops tend to have a VM for everything,
resulting in increased management work.