The 6/28 Virtualization Security Podcast we spoke about attacks, defense in depth, and compliance with Davi Ottenhiemer and Matt Wallace. Davi and Matt just published a book (available on the Virtualization Bookshelf under Security) on how to defend your virtual environment against attack. Unlike other books, this approaches the problem from the point of view of well know attacks. It even gives examples of some of the more interesting attacks against any of the virtual environments, not just VMware vSphere. The discussion eventually found its way to even newer attacks and their impact on the environment.Davi and Matt both work with VMware products extensively, yet their book covers more than one hypervisor. In general, many attacks against one virtual environment will work against another regardless of hypervisor unless the proper defense in depth is applied to the environments in question. And given that many companies use more than one hypervisor understanding the threats to the environment are paramount. There are threats against all levels, not just the ones we see on a daily basis.

Know Your Attacks

The key to all this is know the attacks and their impact to your environment, do not assume that just because you do not know about it, that these attacks will not affect your environment. This means that it is also important to understand all the attack surfaces exposed by your environment. The following diagram shows some if not all the possible attack surfaces:

Defense in Depth: Know Your Attack Surfaces
Know Your Attack Surfaces
Some of these attack surfaces seem to be hard to implement, specifically ones such as virtual machine manager attacks which could result in an escape the VM, or vSwitch attacks as all currently known layer-2 attacks against switching fabrics are mitigated by using virtual switches. Yet, the real problem is not the attack surfaces but the attacks themselves. Many fall into these general categories of attacks and vulnerabilities:

  • SSL MiTM Attacks
  • Web Server Attacks
  • SQL Injection Attacks
  • DHCP/DNS Poisoning/Attacks
  • Storage Attacks
  • Physical Switch Attacks
  • Application Vulnerabilities
  • Protocol Vulnerabilities
  • ARP Cache Poisoning
  • Layer 3-7 Network Attacks
  • Introspection Attacks
  • Administrator Misconfigurations

In general, when this slide is presented, people ask is there anything new? And the answer is that there are very few things that are new and it is not the known attacks, it is the number of surfaces available to attack that has increased.

Defense in Depth

Given that our attack surfaces have increased, we need to plan not only for virtual environment defense in depth, but also increase our physical environment defense in depth, or more to the point control the touch points between the physical environment, the virtual environment, and the cloud environment with many layers of defense, that unless it is needed is invisible to the end user. We cannot impact end user functionality to implement security, but we can have security that is in essence invisible until needed.
This is where many of the virtualization security offload techniques come into the fore as they provide the possibility of invisible security that improves our overall defense in depth leading to failing safe instead of failing open or closed. But it all starts with knowing your attack surfaces and the attacks that are possible against those surfaces. This knowledge can then be used to defend the data worth protecting.

2 replies on “Defense in Depth: Know Your Attack Surfaces”

  1. I’ve been googling to trying to find those XCCDF and SCAP resources for Vsphere 5 and no joy. Are they behind some login somewhere?

    1. Hello Steve,
      There are very few ESX specific SCAP rules, but they are within SCAP itself actually. Someone codified a few. The problem with SCAP as it stands (or openscap) is that you need to be on the host in question to run the current rules, unless you have a 3rd party tool that does some translation to run remotely.
      vCenter Configuration Manager also has XCCDF based rules for its checking as well. I do not think the rules are public yet.
      There is work to get a set of public ‘remotely’ accessed checks. The work however is not trivial.
      Best regards,
      Edward

Comments are closed.