CSA Presentation 26th May Virtualization securityv2


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CSA Presentation 26th May Virtualization securityv2

  1. 1. Bryan Nairn, CISSPSenior Manager, Trustworthy ComputingMicrosoft Corporationbryan.nairn@microsoft.com
  2. 2. Why should I care? Server virtualization is now a given in the majority of enterprise datacenters – source IDC The virtual server and virtual server management software market is forecast to reach a market opportunity of approximately $4.1 billion by 2014. This represents a CAGR of 13.1%. – source IDC Over 40% of production virtual machines will be less secure than their physical counterparts through 2014 – source Gartner
  3. 3. Virtualization powers the cloud Private Cloud Public Cloud• Mimics public cloud • Available to anyone• Benefits enterprise with a network users connection• Highly virtualized • Pay-as-you-go• Strings together IT • Multi-tenant and infrastructure into virtualized resources pools • Self-service portals
  4. 4. Virtualization is a good thing!
  5. 5. Some Common VM Security Myths “I only have to patch my host OS / Kernel” “If I protect my Host machine, it will protect my VMs.” “Virtual Hard Disk files are secure by default.” “If you expose the virtual machine, you have to expose all virtual machines and the host.” “All virtual machines can see each other.” “I don’t need Anti-Virus with Virtualization”
  6. 6. Protection Rings
  7. 7. Virtualization Architecture- Hypervisor Primary Partition Child Partitions Virtualization Stack WMI Provider Applications VM VM Worker Service Processes Ring 3 MinWin Virtualization Virtualization Service Service Providers Clients Windows (VSPs) (VSCs) Guest OS Kernel IHV Kernel Drivers VMBus VMBus Enlightenments Ring 0 Windows hypervisor Ring “-1” Server Hardware
  8. 8. Hypervisor Security Assumptions Guests are untrusted Trust relationships  Parent must be trusted by hypervisor  Parent must be trusted by children Hypercall interface will be well documented and widely available to attackers All hypercalls can be attempted by guests Can detect you are running on a hypervisor + version The internal design of the hypervisor will be well understood
  9. 9. Hypervisor Security Goals Strong isolation between partitions Protect confidentiality and integrity of guest data Separation  Unique hypervisor resource pools per guest  Separate worker processes per guest  Guest-to-parent communications over unique channels Non-interference  Guests cannot affect the contents of other guests, parent, hypervisor  Guest computations protected from other guests  Guest-to-guest communications not allowed through VM interfaces
  10. 10. Hyper-V Isolation No sharing of virtualized devices Separate VMBus per VM to the parent No sharing of memory  Each has its own address space VMs cannot communicate with each other, except through traditional networking Guests can’t perform DMA attacks because they’re never mapped to physical devices Guests cannot write to the hypervisor Parent partition cannot write to the hypervisor
  11. 11. Hyper-V Security Hardening Hypervisor has separate address space  Guest addresses != Hypervisor addresses No 3rd party code in the Hypervisor Limited number of channels from guests to hypervisor  No “IOCTL”-like things Guest to guest communication through hypervisor is prohibited No shared memory mapped between guests Guests never touch real hardware I/O
  12. 12. Hyper-V Security Model Uses Authorization Manager (AzMan)  Fine grained authorization and access control  Department and role based  Segregate who can manage groups of VMs Define specific functions for individuals or roles  Start, stop, create, add hardware, change drive image VM administrators don’t have to be Server 2008 administrators Guest resources are controlled by per VM configuration files Shared resources are protected  Read-only (CD ISO file)  Copy on write (differencing disks)
  13. 13. Virtualization Attack Vectors Host Hardware Virtual Machine Host OS Virtual Machine Hard Disk Files Virtual Machine Configuration Files Remote Management/Control interfaces Guest Operating System Virtual Networks
  14. 14. Common Attacks: Host  Host Compromise for  Deployment, Duplication and Deletion  Control of Virtual Machines  Direct Code / File injection to Virtualization File Structure  Virtual Hard Disks  Virtual Configuration Files  Time Sync  Hardware  Rootkits / Malware  Drivers (Attack Surface / Stability)
  15. 15. It’s all about the what’s underneath…
  16. 16. Use Remote Management All Virtualization Solutions include some form of remote control.  Access to these tools should be limited.  Limit scope of access / control Protect the remote control mechanisms!  Use limited use accounts for control  Make sure the connections are encrypted / authenticated (SSL, RDP over SSL)  Use logging VM VM VM VM VM VMVM VM VM VM VMVM VM VM VM VM VM V VMVM VM VM VM VM M
  17. 17. File Types and Locations .vhd disk file – In folder you specify in settings .vhdd disk file – In folder you specify in settings .vud disk file – In vmc-file folder .vsv disk file – In vmc-file folder
  18. 18. Common Attacks: Guest Unpatched Virtual Machines Older Operating Systems Test or Development machines (these often are not managed in the same way as production machines) Un-managed or user deployed virtual machines Backups and archives
  19. 19. Guest Attacks  The Virtualization File Structure  Virtual Hard Disks  File / Code Injection  Can be Directly Mounted / accessed  Virtual Configuration Files  Base Configuration changes  Redirection / addition of Virtual drives / Resoures  BIOS <hardware> <memory> <ram_size type="integer">256</ram_size> </memory> ... <pci_bus> <ethernet_adapter> <controller_count type="integer">2</controller_count> </ethernet_adapter> </pci_bus> </hardware>
  20. 20. VHD Redirection
  21. 21. Threat Landscape: Virtualized Attackers? Is this is one of the next big attack vectors on the horizon? The VM industry is focused on securing the VMs from attack. Very little thought of VMs being used as the attacker. Cases are starting to appear where people use VMs to attack, then shutdown the VM to remove any trace of evidence.
  22. 22. Threat Landscape: Virtualized Attackers? But we do write all events to the SysLog Things that go into drive slack are recoverable using forensics tools We still have network traces… …and audit logs …and firewall and router logs …not to mention video cameras in the server room.
  23. 23. Defending Yourself
  24. 24. Host Attacks: Potential Solutions  Harden the Host Servers  Where a Hypervisor or Specialist Kernel is used, the Host attack surface is smaller, however updating and patching is still required.  Use single role servers and remove unwanted and un-necessary services / attack vectors  Use a local firewall and only allow limited host control / management ports over encrypted and authenticated channels.  Use limited scope admin accounts with strong passwords  Protect the Virtual Machine files  Access Control Lists (limited to the security context for the users who manage them and the services that control them.  Encryption  Disk / Volume / Folder / File  Auditing  file access, creation, deletion …  Don’t forget the backup files / archives
  25. 25. Guest Attacks: Potential Solutions  Harden the Guest Operating Systems  Treat the guest OS as if it was a physical machine  Isolate the machine with Virtual Networks / VLANs  Local Only Access  NAT  Segmented networks  IPSec Isolation  Physical Isolation (Separate NICs)
  26. 26. Use Access Control Lists Deny Read-only Read/Write• Cannot • See the VM in • See the VM in modify VMC web console web console file and VRMC and VMRC• Will not • Can interact • Can interact appear in with VM with the VM web console • Cannot start, • Can start, or VMRC stop, pause stop, pause, or resume resume VMs VMs
  27. 27. Deployment Considerations Minimize risk to the Parent Partition  Use Server Core  Don’t run arbitrary apps, no web surfing  Run your apps and services in guests Moving VMs from Virtual Server to Hyper-V  FIRST: Uninstall the VM Additions Two physical network adapters at minimum  One for management (use a VLAN too)  One (or more) for vm networking  Dedicated iSCSI  Connect to back-end management network  Only expose guests to internet traffic
  28. 28. Anti-Virus & BitLocker… Parent partition  Run AV software and exclude .vhd Child partitions  Run AV software within each VM BitLocker  Great for branch office  Can be used within a VM  http://blogs.technet.com/virtualworld/archive/2008/02/16/using- bitlocker-under-virtual-pc-virtual-server.aspx
  29. 29. Conclusions Reduce the attack surface on the Host Use least privilege access Audit the deployment, maintenance, control and access to virtual machines Leverage backups, snapshots and redundancy to reduce impact of Host / Guest maintenance Secure your Virtual Machine Hard Disk and configuration files, including backups and archives Use Virtual Networks / VLANs / IPSec to Isolate machines, especially before they are exposed to the network.
  30. 30. Resources Step-by-Step Guide to Getting Started with Hyper-V  http://technet2.microsoft.com/windowsserver2008/en/library/c513e254- adf1-400e-8fcb-c1aec8a029311033.mspx?mfr=true Virtualization Team Blog  http://blogs.technet.com/virtualization Microsoft Virtualization Website  http://www.microsoft.com/virtualization Using BitLocker under Virtual PC / Virtual Server  http://blogs.technet.com/virtualworld/archive/2008/02/16/using-bitlocker- under-virtual-pc-virtual-server.aspx
  31. 31. We would all rather be doingsomething else..