Implementing a Zero Trust Security Architecture

The old mantra of “trust but verify” just isn’t working. “Never trust and verify” is how we must apply security in this era of sophisticated breaches.

Looking at 2014 in the rear-view mirror there has been a myriad of security breaches. Target’s breach exposed over 40 million credit card numbers, 70 million pieces of personally identifiable information resulting in over 1 billion dollars in related costs(1). To further the hit list of this years victims, as of late November 2014, Sony Pictures Entertainment’s entire corporate network is offline due to a suspected breach, which has seen staff cease electronic work entirely due to a corporate wide, self imposed network shutdown(2).

In a time where attacks are both prevalent from inside and outside of business IT and security departments must ask themselves the question Who can you trust?

This blog first appeared on NetworkInferno, vNetadmin and

What is a Zero Trust Model?

In 2013 Forrester published a cyber security framework called the Zero Trust Model. The paper proposes a vendor neutral approach to changing the way cybersecurity is thought about. The major benefits of a Zero Trust Model include:

  • Zero Trust is applicable across all industries and organizations
  • Zero Trust is not dependent on specific technology or vendor
  • Zero Trust is scalable


To implement such a model there needs to be a shift in how people see information and security architectures. The notion of a trusted network (usually seen as internal) and an untrusted or lower security network (external) must be removed. In a world of Zero trust, all network traffic is untrusted. The three technology enablers of this are:

  1. Ensure all resources are accessed securely regardless of location
  2. Adopt a least privilege strategy and strictly enforce access control
  3. Inspect and log all traffic

These three key facets to a Zero Trust Model allow security professionals to scale their security posture and approach enforcement a new manner.

Why is a Zero-Trust Model any Easier with NSX?

Micro-segmentation and Service Composer transform the way security is applied in the virtual data center, making “Zero Trust” a reality.


VMware NSX also provides a stateful firewalling capability, distributed every NSX enabled hypervisor, known as Distributed Firewall (DFW). The DFW, applied between the virtual NIC (vNIC) and vSwitch is image07integrated into the hypervisor kernel and provides near-line rate firewall throughput, scaling horizontally as hosts are added in the data center.

The DFW allows administrators to wrap security controls around the virtual machine itself, removing the dependence on in-guest firewalling which is often easily compromised by application based exploits. In addition, having a firewalling capability right at the VM’s point of entry to the network allows for a vastly different approach to the traditional multi-tier app equals multiple-subnets in the network and 3 legs off the firewall, e.g.:


Figure 1 – Unit-level segmentation

With NSX DFW, a single layer 2 network segment can now be divided into “micro-segments” where all that’s required is a security policy to define the different application tiers. So the 3 Tier app which normally requires 3 VLANs, 3 Subnets and 3 firewall legs now becomes:

Firewall rules are managed centrally using Service Composer (see below), yet the compiled rule set is actually pushed out as a filter to each hypervisor and is specific to each virtual machine. Filtering is stateful and can be applied from layer 2 to 4. Rules can match on MAC, IP, Port plus on specific data center objects, like VM security tag, VM name, Port Group or Logical Switch attachment, Cluster membership and many other criteria.

NSX DFW also offers the ability to do service chaining where IDS/IPS and Anti-Malware virtual appliances from best-of-breed security vendors can be inserted inline between virtual machines – something that has been traditionally very hard to do.

VMware NSX Service Composer

VMware NSX introduces a capability known as Service Composer, which allows helps you provision and assign firewall policy and security services to applications in a virtual infrastructure. You map these services – in the form of a policy – to a security group, and the services are applied to all virtual machines that are a member of that security group.


Figure 2 – Service Composer

Services such as IDS/IPS, anti-malware and next-gen firewalling can be inserted into the traffic flow and effectively chained together between VMs on a granular, per workload basis. API driven tagging of VMs allows services to be applied dynamically, allowing instant reaction to new threats. NSX and Service Composer provides the foundation for creating granular, zero-trust security architectures as discussed below.

Security Groups

A security group defines the assets (virtual machines, IP ranges etc) that you want to protect. Security group membership may be static i.e. a specific VM or set of VMs can be made a member or dynamic where membership may be defined in one or more of the following ways: 

  • vCenter containers such as clusters, port groups, or datacenters
  • Security tags, IPset, MACset, or even other pre-existing security groups. An example of this could be to include in a “Quarantine” Security Group any VM tagged with a security tag of “AntiVirus.virusFound”
  • Directory groups exposed to NSX if Active Directory is registered to NSX Manager
  • Regular expressions such as virtual machines with ‘custA’ or ‘web’ in their name
  • Operating System of the Virtual Machine

Note that dynamic security group membership is being continuously assessed. For example, a virtual machine tagged with the AntiVirus.virusFound tag might be added to to the Quarantine security group due to a match on the tag. When the virus is cleaned and this tag is removed from the virtual machine, it is then dynamically removed from the Quarantine security group. Note that when a VM becomes a member of a new a new group, it typically remains a member of any existing groups. So a policy weight is used to determine which firewall rules are applied first (see below).

Security Policy

A security policy is a collection of stateful firewall rules and/or specific security service configurations.

Security features provided by a security policy

  • L2-L4 Stateful Firewall rules that define what traffic is allowed to, from or within a security group. Note that the rule enforcement point is in the vSphere hypervisor  between the vNIC and vSwitch – thus creating a rule that denies VM to VM traffic for VMs on the same subnet is achieved with just one rule. This capability, while similar to private VLANs, provides far greater flexibility as specific ports can still be permitted while all others can be denied..
  • Guest Introspection  services for data at rest such as Anti-virus, Vulnerability Management and Data Loss Prevention (DLP) scanning.
  • Network Introspection services for data in-flight such as Intrusion Detection/Prevention (IDS/IPS) next-generation firewalling and WAN optimisation.

Attaching a Security Policy to a Security Group

Administrators can attach a security policy (say SP1) to a security group (say SG1). The services configured for SP1 are then applied to all virtual machines that are members of SG1.

If a virtual machine belongs to more than one security group, the order in which services are applied to the virtual machines depends on a weight value  applied to  each security policies attached to the security group in question – whereby the higher weight policy rules are applied first, followed by the rules in the lower weight policies.

Zero-trust in practice

A Zero Trust Model with VMware NSX Distributed Firewall and Service Composer is built around the fact that policy can be applied to the workload, dynamically enforced, anywhere within the infrastructure, and implemented right at the virtual machine’s connection to the vSwitch.

The image below depicts the implementation of a Zero-trust model. Traditional security zones are represented here by the colored rectangles. Each Zone is constructed using an NSX Security Group and has Virtual Machines or in some cases physical machines as members. (physical machine group membership is based on an “IP Set” i.e. a list of IPs or subnet(s) that defines physical hosts). An NSX Security Policy (red cylinder in diagram) is then attached to the Security Group, where access to or from that group is required.


Figure 3 – Zero Trust model

The Zero Trust model applied in Figure 3 – Zero Trust model is such that all users – even those on the WAN – are considered external to the data center. All traffic to the application front end (Zone 1 – Web Tier in this example) must enter via existing physical perimeter firewalls and then be proxied in the DMZ via a set of application gateways..

It’s then only the Application Gateways such as Reverse Proxies and Web Application Firewalls (WAFs) that are allowed to reach the front end of the Zone1 Web servers. This ensures that all traffic to the application, regardless of its source is inspected, validated and permitted only once the application gateway allows it.

Note also that within the Zone1-Web Tier we’ve illustrated that these VMs are on the same Layer 2 network, however as shown by the small firewall icon, security enforcement is applied right at the vNIC so the Zone1 policy can easily deny VM to VM traffic within the group, regardless of the underlying network between these VMs.

To see how these Security Groups are represented within NSX, we open up the the Service Composer Canvas view:

image03Figure 4 – Service Composer Canvas

Looking at the VM-In-Production Security Group in Service Composer,a click on each icon reveals: which VMs currently belong to the group the policies that apply to it; and what is being enforced. For example, a click on the blue icon representing Virtual Machines displays a list of dynamically added VMs.


Figure 5- Virtual Machines matched by Service Composer

”Production” is a Security Policy that is applied to the “VM-In-Production” Security Group and includes VMs that are already a member of Zone1-Web, Zone2-Application, and Zone3-Database Service Composer groups. A Security Policy is also applied to Zone1-Web, Zone2 and Zone3, so VMs that are members of both the Zone policy and the “Production policy will have rules applied in the order of the weight assigned to each policy.

In this example, the Quarantine Policy has been given the highest weight and thus Quarantine firewall rules will move to the top of the Firewall rule table shown in Figure 6 – Security Policy Weighting.

image05Figure 6 – Security Policy weighting

This ensures that a VM in the Quarantine group is denied network access before other rules are processed that might grant network access further down in the rule table.

As a consequence of weighting applied to each policy as per the diagram above, a VM that is a member of the two groups where Zone1 AND Production policies have been applied, will have Zone1 rules applied first followed by Production rules in the firewall rule table.

Here’s the firewall rule table generated by Service Composer and the policy weighting shown above. As you can see the Quarantine group is first and contains a Block action for Source of the Quarantine group and Destination any: 


Figure 7 – Quarantine Group in Firewall view

Further down in the rule table, a VM in the VM-In-Production group gets access to essential network services like DNS and Active Directory. This is represented by the VM In-Production Security Group in Figure 3 – Zero Trust model. Below in Figure 8 – VM In-Production Policy is the relevant rules.


Figure 8- VM In-Production Policy

Note also that clicking on the Policy icon in Service composer also reveals which policy and thus firewall rules and services have been applied to VMs in this Security Group. This is highlight below in Figure 9 – VM-In-Production Security Policy.


Figure 9 – VM-In-Production Security Policy

The Production Security Policy has three rules which match on source, destination, service and then performs an action. Rule 1 is defined to match the source based on Policy’s security group it is attached to the destination Zone5-Production Security Group. It is matching on DNS and Microsoft AD services and permitting these.


Figure 10 – Production Security Policy

The Figure 11 – Zone1-Web Canvas shows members of the Zone1-Web group. This particular topology has been deployed via a vRealize Automation blueprint. Built in to the blueprint is the instruction to add these VMs to the Zone1-Web security group at provision time, thus security is automatically applied to these web application VMs without manual intervention or manual creation of firewall rules.


Figure 11 – Zone1-Web Canvas

To find out what Security Policy is being applied to Zone1-Web click the Security Policy icon on the Service Composer group shown in Figure 12 – Zone1-Web Security Policy Canvas.


Figure 12 – Zone1-Web Security Policy Canvas

On closer inspection of the Web-Tier Security policy in Figure 13 – Web-Tier Access Policy overview, we can see that SSH, HTTP and HTTPS (22, 80, 443) are being permitted from Zone0-DMZ to Zone1-Web. The policy then allows any communication between Zone1-Web and Zone2-Application. It would be very easy from here to restrict what is being communicated further by isolating Application only ports.


Figure 13 – Web-Tier Access Policy overview

To ensure nothing can communicate to applications of machines other than those specified, a Default All Server VMs policy is created which has an implicit deny any any rule associated to it. This ensures all workloads within this security architecture cannot communicate to anything unless explicitly specified.

Looking at the logical security topology, an administrator can easily  determine how to protect and enforce application topologies across the infrastructure. Jump hosts  can be authorised to reach specific targets in the data center based on the Active Directory credentials of the user that is logged into that jump host.

So, because NSX simultaneously provides centralised policy control (Service Composer) with  distributed enforcement (Distributed Firewall), building a zero-trust model is now operationally viable and provides enforcement where there was previously none.


Figure 14 – Zero Trust model overview


Service Insertion and third-party integration via Network Extensibility

With the use of service composer it is possible to insert additional services for consumption on a per application basis. Using VMware’s Network Extensibility (NetX) framework, third-party partners can integrate into VMware NSX. This allows services such as remediation, advanced load-balancing, packet capture and analysis, IDS/IPS, and anti-virus to be applied to service composer groups. In turn this provides additional services to those applications that require it. Application services are no longer defined by the hardware architecture that exist for a lifecycle of the investment. Services can be dynamically spun up and the torn down based on business requirements that can change rapidly.


Figure 15 – Zero Trust model overview with 3rd Party security integration

Figure 15 – Zero Trust model overview with 3rd Party security integration is an example of Symantec anti-virus scanning being applied the VM In-Production policy. This insertion will provide Symantec’s agent-less anti-virus, anti-malware capability to VM In-Production Service Composer group. The result is that Zone 1 – Web Tier, Zone 2 – App Tier and Zone 3 – Database VMs that are “In-Production” will all receive this service. New workloads assigned to the VM In-Production group will also receive AV scanning. VMs that are destroyed or fall out of the matching criteria of these zones will no longer receive this additional service.

Automatic Policy

Service Composer provides the ability to automate the application of a security policy by leveraging Security Tags. A feature of NSX, Security Tags can be a matching criteria for Service Composer groups and based on what the tags is, additional actions can be taken.

In Figure 15– Zero Trust model overview with 3rd Party security integration. the Quarantine Security group has a match criteria of Security Tag ‘Quarantine’. With the Symantec AV service protecting the VM In-Production Security group, if the VM is found to have a vulnerability, the “Quarantine” tag will be applied. This tag will now make the VM a member of Quarantine group and thus be enforce the Security Policy associated with the Quarantine group. Firewall rules applied to the Quarantine group, will effectively block communication to “any” other address and additionally only permit a connection from the remediation group devices.. The remediation service provided by Rapid7 will clean the VM  and automatically remove the ‘Quarantine’ tag which results in the VM being placed back into production.

Whilst this is a strict and severe remediation policy, administrators can tailor this to their environment. This policy could destroy the VM and deploy another from template, leave in production and notify through Event and Log Notifications or apply additional security controls restricting access to certain assets. This highlights the flexibility of Service Composer, dynamic matching of Security Policy and the powerful nature of automated Service Insertion through our Network Extensibility partners.

Hardening your existing infrastructure from the inside out

Network virtualization with VMware NSX allows simplified integration into brownfields environments seeking to implement zero-trust security policies. The ability to deliver this on a per application basis gives enterprises the edge in securing production workloads without interrupting  production.

With the ability to take existing workloads and enforce security policy in a dynamic and context aware way, without the need for new physical equipment or complex topology changes, makes network virtualization a key tool in revolutionising data center security..


(1) – Target CEO fired for more than security
(2) – Sony Pictures down for a second day after network breach

Further Reading

VMware® NSX for vSphere Network Virtualization Design Guide
WhitePaper: NSX Distributed Firewalling Policy Rules Configuration Guide
Getting Started with Micro-Segmentation with NSX vSphere

About the Authors

Matt Berry – Matt Berry has spent over twenty years in the IT industry and in that time, attained CCIE #10473 while working for AT&T in backbone operations. Matt has also spent time on the customer side of the fence, the channel and other vendors, primarily focused on networking, application performance and data center security. Matt joined the VMware Networking and Security business unit in mid-2013 and can’t get enough hypervisor-based packet filtering and forwarding with VMware NSX. Matt’s now the proud holder of VCP-NV – VMware’s Certified Professional for Network Virtualisation.

Anthony Burke – Anthony is a Systems Engineer within the Network and Security Business Unit (NSBU) at VMware. He delivers scale out data centers powered by network virtualization. Anthony has spent time in the emergency service sector before VMware as a Network Architect of critical infrastructure. He has a penchant for evangelizing and evolving legacy security architectures into something that can handle threats now and into the future. Anthony has a few letters after this name – CCNP, VCP-DCV and VCP-NV for a start. He writes frequently at and can be found on Twitter as @pandom_


Motonori Shindo – Motonori Shindo is a Staff System Engineer at VMware, focusing primarily on NSX, a network virtualization platform by VMware. He is known as a distinguished speaker in the computer and networking industries. He has contributed to many books and magazines, among which “VMware NSX” is the world’s first book specifically about NSX. His blog can be found at

8 thoughts on “Implementing a Zero Trust Security Architecture”

  1. In your haste to sell us on NSX, you missed out on a much more secure “zero trust” network model. One that has been used for years, and for which MSFT of all people provides good management tools.

    All traffic between all machines is encrypted *and* authenticated using IPsec or TLS. There are no inspection middleboxes of any type, as these require sending decrypted data across the network, and historically have terrible security. Hosts have policies which enforce who they talk with on what ports, based on cryptographic identities and not IP address ranges,
    MSFT group policies male this true zero-trust network reasonably easy to deploy. It is a hell of scripting on Unix-like systems, but can be done. Works on any network topology.

    1. Thanks for the reply Ryan.

      Whilst I am a Technical Pre-sales engineer at VMware in the NSBU, I’ll leave the selling to my sales guy :).

      What is presented here is an approach to Implementing Zero Trust. The notion of Micro segmentation and Zero-Trust are concepts that can be stand alone or implemented together.

      Yes, absolutely – There are benefits to other vendors solutions too. Whilst I am not overly familiar with what Microsoft are doing, VMware NSX can provide authenticated, scalable, and dynamic policy as well. At this stage all end point traffic isn’t encrypted. we provide a suitable level of isolation (PCI validated isolation) through VXLAN. NSX does also provide enforcement across Windows and *Nix like systems to allowing enforcement on context as described in the article.

      The main purpose of this post was to show how VMware approach the problem space and what we can do in evolving a security architecture.

      Thanks for posting and please slap me with the wet squid of reality if I come across as a blind, ignorant fool! 🙂

      1. My point was not to pimp MSFT solutions, but that “segmentation” based on encapsulation like VXLAN, NVGRE, or whatever is basically a joke from a security perspective. Just like regular old VLANs. PCI certification means squat; as long as you have a “stateful firewall” you can meet many PCI requirements, even if it has an “allow ANY” ruleset!

        If you’re not using *authenticated* encryption to segment, you’re open to a huge range of attacks from both privileged and potentially unprivileged attackers in the same multi-tenant domain. IPsec or TLS badically obviate the need for any segmentation at the infrastructure layer. It’s how Netflix and Co. use public cloud infrastructure for their critical operations. They simply don’t accept packets from hosts without cryptographic authentication. Once you build the policy infrastructure, this scales linearly, as the “work” is perfectly distributed to every VM in the trusted domain.

  2. Thanks – nice overview with helpful screenshots and diagrams.

    In response to Ryan I’d say you are not comparing like with like. Sure encrypted/authenticated traffic between hosts sounds great and is a must to securely run a service over public cloud. However that’s not a standard Enterprise use case any day of the week whereas a privately hosted 3 tier application most certainly is. Also I’d point out the orchestration/management aspects of per host configuration as you describe is a massive challenge with any solutions likeley developed at great cost by the type of hyper-scale operations you mention. In other words though again not mainstream Enterprise relevant.

    1. Hmm… I’m in the banking industry, and in-datacenter authenticated encryption is not only mainstream, it is actually a requirement for many cases. We have contracts which specifically state “no data may cross any network segment without authenticated encryption” in the security section, then go into gory detail about key management requirements.
      Is banking not “Enterprisey” enough to be a common use case?
      If you’re already using AD, configuration management tools, and an internal Certificate Authority – and most enterprises are – doing IPsec or TLS host-to-host is not a big leap.
      Basically, we should be reducing our trust base as small as possible. Right now that’s the local OS instance; in the future it could be down to the process/container level. There is no “safe” network segment at all; see the Sony hack for an example of why that’s true.

  3. I would like to see how this could be applied to a multi-tenant environment of a service provider, easily and securely with minimized risk of an admin opening or blocking traffic and causing either security breach or DoS.

    In regards to the posts about encryption and authentication, I suppose that both these can help security, but won’t it still be vulnerable if it is host base and one of the hosts are compromised ?

    You are always vulnerable when you have to communicate I guess.

Leave a Reply

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