Home > Cloud Security, Virtualization, Virtualization Security > Incomplete Thought: On Horseshoes & Hand Grenades – Security In Enterprise Virt/Cloud Stacks

Incomplete Thought: On Horseshoes & Hand Grenades – Security In Enterprise Virt/Cloud Stacks

It’s not really *that* incomplete of a thought, but I figure I’d get it down on vPaper anyway…be forewarned, it’s massively over-simplified.

Over the last five years or so, I’ve spent my time working with enterprises who are building and deploying large scale (relative to an Enterprise’s requirements, that is) virtualized data centers and private cloud environments.

For the purpose of this discussion, I am referring to VMware-based deployments given the audience and solutions I will reference.

To this day, I’m often shocked with regard to how many of these organizations that seek to provide contextualized security for intra- and inter-VM traffic seem to position an either-or decision with respect to the use of physical or virtual security solutions.

For the sake of example, I’ll reference the architectural designs which were taken verbatim from my 2008 presentationThe Four Horsemen of the Virtualization Security Apocalypse.

If you’ve seen/read the FHOTVA, you will recollect that there are many tradeoffs involved when considering the use of virtual security appliances and their integration with physical solutions.  Notably, an all-virtual or all-physical approach will constrain you in one form or another from the perspective of efficacy, agility, and the impact architecturally, operationally, or economically.

The topic that has a bunch of hair on it is where I see many enterprises trending: obviating virtual solutions and using physical appliances only:


…the bit that’s missing in the picture is the external physical firewall connected to that physical switch.  People are still, in this day and age, ONLY relying on horseshoeing all traffic between VMs (in the same or different VLANs) out of the physical cluster machine and to an external firewall.

Now, there are many physical firewalls that allow for virtualized contexts, zoning, etc., but that’s really dependent upon dumping trunked VLAN ports from the firewall/switches into the server and then “extending” virtual network contexts, policies, etc. upstream in an attempt to flatten the physical/virtual networks in order to force traffic through a physical firewall hop — sometimes at layer 2, sometimes at layer 3.

It’s important to realize that physical firewalls DO offer benefits over the virtual appliances in terms of functionality, performance, and some capabilities that depend on hardware acceleration, etc. but from an overall architectural positioning, they’re not sufficient, especially given the visibility and access to virtual networks that the physical firewalls often do not have if segregated.

Here’s a hint, physical-only firewall solutions alone will never scale with the agility required to service the virtualized workloads that they are designed to protect.  Further, a physical-only solution won’t satisfy the needs to dynamically provision and orchestrate security as close to the workload as possible, when the workloads move the policies will generally break, and it will most certainly add latency and ultimately hamper network designs (both physical and virtual.)

Virtual security solutions — especially those which integrate with the virtualization/cloud stack (in VMware’s case, vCenter & vCloud Director) — offer the ability to do the following:

…which is to say that there exists the capability to utilize  virtual solutions for “east-west” traffic and physical solutions for “north-south” traffic, regardless of whether these VMs are in the same or different VLAN boundaries or even across distributed virtual switches which exist across hypervisors on different physical cluster members.

For east-west traffic (and even north-south models depending upon network architecture) there’s no requirement to horseshoe traffic physically. 

It’s probably important to mention that while the next slide is out-of-date from the perspective of the advancement of VMsafe APIs, there’s not only the ability to inject a slow-path (user mode) virtual appliance between vSwitches, but also utilize a set of APIs to instantiate security policies at the hypervisor layer via a fast path kernel module/filter set…this means greater performance and the ability to scale better across physical clusters and distributed virtual switching:

Interestingly, there also exists the capability to actually integrate policies and zoning from physical firewalls and have them “flow through” to the virtual appliances to provide “micro-perimeterization” within the virtual environment, preserving policy and topology.

There are at least three choices for hypervisor management-integrated solutions on the market for these solutions today:

  • VMware vShield App,
  • Cisco VSG+Nexus 1000v and
  • Juniper vGW

Note that the solutions above can be thought of as “layer 2” solutions — it’s a poor way of describing them, but think “inter-VM” introspection for workloads in VLAN buckets.  All three vendors above also have, or are bringing to market, complementary “layer 3” solutions that function as virtual “edge” devices and act as a multi-function “next-hop” gateway between groups of VMs/applications (nee vDC.)  For the sake of brevity, I’m omitting those here (they are incredibly important, however.)

They (layer 2 solutions) are all reasonably mature and offer various performance, efficacy and feature set capabilities. There are also different methods for plumbing the solutions and steering traffic to them…and these have huge performance and scale implications.

It’s important to recognize that the lack of thinking about virtual solutions often seem to be based largely on ignorance of need and availability of solutions.

However, other reasons surface such as cost, operational concerns and compliance issues with security teams or assessors/auditors who don’t understand virtualized environments well enough.

From an engineering and architectural perspective, however, obviating them from design consideration is a disappointing concern.

Enterprises should consider a hybrid of the two models; virtual where you can, physical where you must.

If you’ve considered virtual solutions but chose not to deploy them, can you comment on why and share your thinking with us (even if it’s for the reasons above?)


Enhanced by Zemanta
  1. Me
    May 22nd, 2012 at 19:01 | #1

    We chose not to deploy a virtual FW solution for intra VM traffic because none of the solutions listed provided detailed enough logs for administrative activities or had adequate governance/segregation of duties.

  2. May 23rd, 2012 at 00:31 | #2

    (1) For the above reasons – logging & change management of administrative activities; separation of duties.

    (2) We have 10G physical firewalls and simply do not need the potential performance benefit of other solutions. If we saved a millisecond the users will not notice.

    Using virtual technology as an enhancement, not replacement for physical firewalls is a possibility though (micro-perimeter), but we’d still have to figure out how to separate administrative duties, and we’d still end up with multiple overlapping systems for policy enforcement and the overhead that entails.

    • Me
      May 23rd, 2012 at 19:07 | #3

      Nailed it! Woo I saved a microsecond on something or I have major SoD issues

  3. June 26th, 2012 at 09:58 | #4

    A few vendors, such as my employer (Vyatta), are focusing almost exclusively on providing layer 3 services (firewall, advanced routing, NAT, VPN, DHCP . . .) within the hypervisor. While many of our engagements are test and dev. deployments, we are starting to see far more sophisticated, on demand data center instances being offered by cloud service providers. The advantage isn’t from saving a few milliseconds by not hair-pinning traffic through a physical router, no, the gain comes from the agility to be able to deploy a new firewall/VPN on demand without relying on buying/installing/cabling new hardware. With utility pricing, it means there is no capex until you have a customer who needs the service.

  4. Ben93160
    February 6th, 2013 at 09:15 | #5

    In the article, the author said “All three vendors above also have, or are bringing to market, complementary “layer 3″ solutions that function as virtual “edge” devices and act as a multi-function “next-hop” gateway between groups of VMs/applications (nee vDC.) For the sake of brevity, I’m omitting those here (they are incredibly important, however.)”

    Could someone tell me what is the “layer 3” solution from Juniper ? I’v found vShield Edge and Cisco Asa 1000v Cloud Firewall but not the one from Juniper!
    Thanks for your help!!


    • beaker
      February 6th, 2013 at 09:51 | #6

      Hello Benoit…

      Juniper offers the virtual version of the SRX called JunosV Firefly.

      It’s currently targeted for specific use cases in complement to vGW.


  5. Ben93160
    February 7th, 2013 at 02:06 | #7

    Thanks for your quick answer! I saw Firefly is actually in Beta!!


  1. May 23rd, 2012 at 08:09 | #1