An introduction to Zero Trust virtualization-centric security

Filed in NSX, Security, Video, VMware by on June 11, 2014 13 Comments

This post will be the first in a series that examine what I think are some of the powerful security capabilities of the VMware NSX platform and the implications to the data center network architecture.  In this post we’ll look at the concepts of Zero Trust (as opposed to Trust Zones), and virtualization-centric grouping (as opposed to network-centric grouping).

Note: Zero Trust as a guiding principle to enterprise wide security is inspired by Forrester’s “Zero Trust Network Architecture“.

What are we trying to accomplish?

We want to be able to secure all traffic in the data center without compromise to performance (user experience) or introducing unmanageable complexity.  Most notably the proliferation of East-West traffic; we want to secure traffic between any two VMs, or between any VM and physical host, with the best possible security controls and visibility — per flow, per packet, stateful inspection with policy actions, and detailed logging — in a way that’s both economical to obtain and practical to deploy.

Trust Zones of Insecurity

Until now, it hasn’t been possible (much less economically feasible or even practical) to directly connect every virtual machine to its own port on a firewall.  Because of this, the firewall has always been a “thing” (a physical piece of iron, or virtual machine) that we need to bolt on top of the network.  First, you need a network to connect, aggregate, and group machines.  After that you can connect the firewall to a port on that network-centric grouping (a virtual switch Port-Group and/or VLAN).  Meanwhile, the network construct establishing the group provides unfettered connectivity within the group.  In other words, the firewall has no visibility or security control over the East-West traffic between machines in given group.  The result is a “Trust Zone”.  We “trust” (read: hope), but can’t verify, that one machine in the zone will not laterally infect/attack the other zone members.

Unsecured Trust Zones

Network-centric grouping in a virtual environment

Groups form the basis of a security policy.  Similar machines from a policy standpoint are placed into a group, at which point a policy governs how traffic is handled in to, out of, and within that group.  How these groups are defined and where they exist can make a big difference in a virtualized data center.  For example, when groups are defined by a networking construct, and then pushed into a virtual environment (vSphere), the security policy attached to a virtual machine is determined by its connection to a specific network-centric grouping object, with the most minimal granularity being a Port Group.  Taking a network-centric approach in a virtual environment presents a number of challenges.

First, this approach can quickly create a large quantity of networking objects to deal with — a morass of Port Groups cluttering the virtual network inventory.  For example, lets say you have 100 applications, each with three distinct tiers of policy groups (Web, App, DB); this would result in 300 Port Groups to choose from in your distributed virtual switch.

Second, the virtual administrator needs to correctly choose, and manually attach, the specific Port Group for each virtual machine network interface when it’s deployed.  With an inventory of hundreds or thousands of virtual machines and Port Groups to choose from, human error in applying the wrong security policy is something to contend with.  Despite the clutter of Port Groups, the manual aspects can be mitigated however if there is good integration with upstream automation software, namely vCloud Automation Center (vCAC).

Third, a Port Group is an object that’s specific to one distributed virtual switch (DVS). If the security policy for a virtual machine depends on its connection to a specific Port Group, the mobility domain for that virtual machine is limited to one DVS. Migrating outside of the DVS would involve a cold stop/start operation, and manually attaching the virtual machine to a different and specific Port Group in a new DVS.

Fourth, there are no security controls for East-West traffic within the Port Group that establishes a group.  It’s just another “Trust Zone”.  Only traffic between groups can be secured; which might lead to an effort to obtain more granularity by creating more and more Port Groups.

Zero Trust transparent security

In the Zero Trust model, we take the usual Firewall-bolted-on-top approach and turn it upside down.  Every virtual machine is first connected to a transparent in-kernel statefull firewall filtering engine (with logging) before it’s even connected to the network.  This means that any traffic to or from a virtual machine can be secured, regardless of the network construct it’s attached to.  Because the firewall is below the network, directly adjacent to the things we want to protect, there is never an unfettered “Trust Zone”.  Security is omnipresent — per flow, per packet, statefull inspection with policy actions and detailed logging, per virtual machine, per virtual NIC.  The network constructs still exist, of course, but only to provide connectivity (not security).  The Zero Trust model is also referred to as Micro Segmentation.

Zero Trust transparent security

Virtualization-centric grouping in a virtual environment

A security policy works with the basic concept of a group, comprised of similar objects, to which you then apply a policy based on group names.  In the network-centric model these groups were represented by Port Groups in a distributed virtual switch.  In contrast, another approach is to employ a virtualization-centric grouping model, as implemented by VMware NSX, where the groups that form the basis of your security policy are decoupled from the network, and are simply an abstract object called a “Security Group” existing in the virtualization layer.  There are a number of advantages to this approach in a virtual environment (e.g. vSphere).

First, the virtual network inventory remains simple and uncluttered.  For every Security Group created there is no requisite and corresponding Port Group to create.  The virtual network inventory remains constant as the environment grows.  For example, this time your 100 applications, each with distinct tiers of policy groups (Web, App, DB), can be deployed with only one Port Group and VLAN providing the network connectivity.

Second, the virtual environment can dynamically attach virtual machines to the appropriate Security Group based on virtualization relevant context, tags, and business logic.  As a simple example, in the diagram above, any VMs with the name “PROD-web” are placed in the “Web” Security Group automatically.  Another scenario might be; if VMs are deployed by members of the “Engineering” active directory group, tag them as “Engineering”, and based on that tag dynamically add them to the “Dev/Test” Security Group, and isolate them from “Prod”.  It doesn’t matter which Port Group the VMs are attached to.  An incorrect Port Group assignment might only break network connectivity, not security policy.

Third, mobility is not artificially limited a network-centric object such as a single distributed virtual switch.  Security Groups are not coupled to a distributed virtual switch (DVS), or any network construct for that matter.  It doesn’t matter which Port Group connects to your virtual machine, and by consequence it also doesn’t matter which DVS your virutal machines are connected to either.  This means you can live migrate virtual machines from one DVS to another; and someday soon, between vCenter instances — all while maintaining consistent security policy.

And finally, as previously discussed, there are no insecure Trust Zones with virtualization-centric grouping.  Even traffic within a Security Group can be subject to policy controls and statefull inspection with detailed logging.  The highest degree of granularity is provided at the onset (per virtual machine, per virtual nic).

Architecture implications

With a transparent firewall underneath the network, as opposed to bolted on top, this will have implications to the data center network architecture.  The result, I contend, will be virtual and physical topology simplification.

When the firewall is bolted on top, the network substrate needs to be designed in such a way that correctly implements a security policy — selectively steering traffic from a virtual machine to some physical or virtual firewall several hops away.  The more granularity you attempt, the more complex the design becomes with a quagmire of network-centric traffic steering and isolation tools like Port Groups, VLANs, ACLs, and VRFs.  Meanwhile, more and more East-West traffic needs to be detoured several hops to a firewall, impacting performance (user experience). And in the end, you’re still left with unsecured Trust Zones, as you can never realistically obtain per-VM granularity.

With virtualization-centric VMware NSX, on the other hand, policy is applied underneath the network, in the virtualization layer.   Throw away that East-West traffic detouring bag of tricks.   Security is applied, transparently, before the packets even arrive at the first virtual network port.  Latency sensitive East-West traffic is free to travel directly to its destination, taking the lowest latency path, having already been secured at the onset.

The network architecture is simply designed for connectivity; whether that might be a handful of VLAN backed Port Groups in an L2 fabric that you’re already using today; or migrating toward full network virtualization with VXLAN backed Logical Switches, Logical Routers, and simple L3 farbrics.  You can start with the former and gradually move to the later.

Some points of differentiation

When evaluating options and comparing the security capabilities of VMware NSX for vSphere to other solutions, here are some points of differentiation to keep in mind.

Headless operation — The VMware NSX for vSphere distributed firewall does not rely on some other virtual machine for the data plane to function. Rules are centrally programmed by the NSX Manager and each host is able to inspect and enforce security policy for every flow and packet on its own, without the Manager (including headless vMotion).

Mobility — Your virtual machines are not constrained to single distributed virtual switch. Security policy is consistent irrespective of the DVS or Port Group providing the connectivity, and virtual machine live migration is not artificially constrained to a single DVS.

Zero Trust — Even traffic within the most minimal grouping construct is secured.  East-West traffic within a Security Group, can be subject to policy, statefull inspection, and logging.  There are no insecure Trust Zones.

Automation — The virtual environment can automatically attach virtual machines to the appropriate Security Group and subsequent policy based on virtualization relevant context.  The virtual administrator doesn’t need to correctly choose and manually assign virtual machines to a specific Port Group.  And when a host is added to a cluster, all of the required software is automatically installed.

Dynamic security — Just as the virtual environment can automatically assign a virtual machine to a Security Group, based on context, it can also change the Security Group (and policy) dynamically, based on changing context, or context provided from a third party, such as a malware or vulnerability assessment solution (Rapid7, McAfee, Symantec, Trend Micro).

Distributed platform for NGFW — One of the policy actions you can apply to a Security Group is selectively redirecting traffic to a local user space service virtual machine on each host.  For example, 3rd party firewall providers can leverage this platform to add NGFW inspection to the environment in a distributed manner.  Palo Alto Networks has already leveraged this capability with their VM-Series NGFW firewall that integrates with VMware NSX for vSphere.

Quick Video Demonstration

Finally, here’s a quick video demonstrating the scenario depicted in the diagrams above.  I will show how a Security Group is created, how virtual machines are automatically assigned to a group, how East-West traffic within this group can be filtered by the NSX statefull firewall, and how the logs can be viewed and analyzed.




About the Author ()

Brad Hedlund is an Engineering Architect with VMware’s Networking and Security Business Unit (NSBU), focused on network & security virtualization (NSX) and the software-defined data center. Brad’s background in data center networking begins in the mid-1990s with a variety of experience in roles such as IT customer, systems integrator, architecture and technical strategy roles at Cisco and Dell, and speaker at industry conferences. CCIE Emeritus #5530.

Comments (13)

Trackback URL | Comments RSS Feed

  1. Matt Nabors says:

    Looks a lot like the latest version of Cisco’s TrustSec. It appears to app least be a similar concept. I think it’s a good thing that industry leaders are doing something like this in such a similar fashion. Lends credibility to the idea. Excellent explanation of the concept. Thanks!

  2. Mike Fratto says:

    Another great explanation, Brad. Thanks. Quick question: How would this zero trust model include physical machines that need to interact with VMs?

    • Brad Hedlund says:

      Thanks Mike!
      I’ll cover how to secure physical to VM traffic in a future post, but basically the short answer is that you can add IP addresses as an object in a Security Group. When you apply policy to that group, the rules in the firewall will be programmed accordingly.


      • georgi says:

        Agreed, we did this at my previous job using Juniper’s vGW and Cisco 1000v, good to see vmware is streamlining the whole thing under one roof!

  3. Kelly McDowell says:

    Great post, very well explained. Clear explanations like this will go a long way to help others understand the benefits.

    One question about this, can you address what happens to guests that need storage access directly for NFS or iSCSI? I would presume, for performance reasons, that you aren’t recommending the fw be places on those NICs? Is there a process to exempt a vNIC or would you simply make that other vNIC part of a different vswitch to avoid the firewall?

  4. Moamen Elhefnawy says:

    Great Explanation as usual.

    I just need to know the differences between this solution and any other Virtual firewall like Cisco VSG , PaloAlto, are they using the same concept?

    Thanks again for your great article.


    • Jeremiah Cornelius says:

      The other firewalls you mention may be delivered in a virtual appliance form factor, and attach to the virtual switching fabric. The NSX DFW is resident in ESX kernel, and intercepts traffic at L2 – much as a MAC-spoof in the physical world.

      However, logically the insertion point is at the vNIC of a VM. The FW is “bump in wire” on EVERY WIRE. Logical abstractions for managing the connection policy and state of the NSX DFW are simple and flexible, leveraging the Service Composer or related REST.

      PaloAlto are working with this model, and their virtual firewall may be added for DPI NGFW capability. They achieve a benefit of examining pre-filtered traffic after DFW tuples are enforced.

  5. I am experiencing some small security issues with my latest virtual machine and from last few days, I was finding something more secure. I would like to consider your centric security ideas to secure my data. It emphasizes the security of the data traffic itself rather than the security of networks, applications, or even simply data. Thanks Brad for this excellent post!

Leave a Reply

Your email address will not be published. Required fields are marked *