2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

 SHOW

VxPlanet

An NSX Blog

NSX Microsegmentation Part 1 : Developing the Architecture

November 30, 2022December 6, 2022 Posted in VMware NSX

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 1/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Distributed Firewall (DFW) is one of the powerful security features of NSX. Distributed Firewall is an East-West Firewall used for network
segmentation and microsegmentation to achieve zero-trust protection for the environment. The DFW exists in the kernel of the hypervisor
and the rules are enforced at the vnic level of the virtual machines. DFW rules moves with the VM during vMotion events and as such the
traffic flow table and state information is preserved.

One of the big use cases of DFW is microsegmentation. Micro-segmentation enables us to logically segment the datacenter into different
security zones, down to the individual application (or application tier) level and then define unique security policies for the application.
Basically we define who access what, how and when. For example, for a web application we can control who has access to the application,
how the application is accessed (over what protocols) and when the policies are enforced (using dynamic time based controls). With secu‐
rity controls around each zone or application, also known as ring-fencing, lateral movement from a compromised device is prevented.

Implementation of zero trust security requires proper designing of a microsegmentation architecture. This requires a lot of data and thor‐
ough understanding of the customer environment, the applications, it’s locations, services, traffic directions etc. This information is cap‐
tured from various methods like:

Customer interviews
Auditing the customer environment through inventory workshops
Using Netflow/IPFix tools like vRealize Network Insight
Review / audit of the existing firewalling solution
NSX Intelligence
Auditing customer inventory management systems (CMDB)

In part 1 of this blog post, we will design a microsegmentation architecture and develop a security blueprint using a fictitious customer en‐
vironment. In Part 2, we will transform the developed design to DFW rules to achieve zero-trust security.

Advertisement

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 2/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

NEW NEW NEW

833.33 AED 833.33 AED 852.38 AED

795.24 AED 728.57 AED 852.38 AED

Note : The customer and scenario described below is completely fictitious. The below environments, applications, app-tiers, procedures
etc are completely based on assumptions and can be used as a reference to develop a microsegmentation strategy for learning purposes.

Lets get started.

Fictitious customer environment (Corp-XYZ)

After conducting interviews and initial discovery sessions with the fictitious customer, Corp-XYZ, we have the below findings:

Customer is planning to microsegment a portion of their virtualized infrastructure which comes under a specific business unit (let’s call
the BU as BU-ABC).
BU-ABC has six environments that support application development, testing and hosting.
Development
Test
UAT
QA
Staging and
Production
Production workloads span across multiple VLANs. They have few access controls for production at the firewall which is the default
gateway for each VLAN. Non-Prod environments are restricted within each environment’s VLAN.
All workloads are hosted on multiple vSphere clusters managed by a single vCenter server and a single NSX instance.
vSphere management cluster
Non-Prod cluster
https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 3/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Prod cluster
Workloads are hosted on multiple OS platforms – Windows and Linux
A centralized perimeter firewall is in place for North-South protection. No east-west protection in place.
They have six applications each having it’s own instance in each environment. ie, a total of 36 application instances across all the
environments.
E-commerce website
Intranet
CRM
Search service
Live News and
Upload services
Each application is multi-tiered and has dependencies with other application tiers too.
Currently no strict access controls in place for management access to the workload VMs. Security is controlled through user privileges
only and not from where the workloads are accessed.
All environments talk to common infrastructure services – AD, DNS, NTP, FTP, WSUS, DHCP, AV, monitoring, backup etc.
No physical or other hypervisor based workloads.
DMZ is currently physical and is not in scope.

The fictitious customer also shared the asset data they had – environment details, application build specifications, services list and other
CMDB items for review.

Additional findings post data review and infra assessment

After performing further infrastructure assessment, audit of collected information and review of output from Netflow tools, we have the
below findings to start working on initial design of microsegmentation architecture for Corp-XYZ.

Applications under the Test environment are least critical and can afford downtime without change management. This environment is
a good candidate to test microsegmentation policies before rolling out to other environments.
E-commerce website has four app-tiers on each environment. It has dependency with search-tier in the Search application for search
engine functionality.
web-iis-tier
db-tier
log-tier
idp-tier

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 4/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Intranet application has two tiers on each environment. It has dependency with E-commerce website application for db-tier and idp-
tier. It also has dependency with search-tier in the Search application for search engine functionality.
web-iis-tier
log-tier
CRM application has three tiers. It has dependency with search-tier in the Search application for search engine functionality.
web-iis-tier
db-tier
log-tier
Search service has one tier. It has dependency with E-commerce website application for db-tier
solr-tier
Live News service has two tiers. It has dependency with search-tier in the Search application for search engine functionality.
web-iis-tier
log-tier
Upload service has one tier:
ftp-tier
Only Production environment has FTP upload service, and the upload tier has replication to all other environments.
The below services / ports are used in each application tier:
web-iis – Microsoft IIS / TCP 80, 443
log – Custom logging application / UDP 514
db – Custom database / TCP 3306
ftp – Microsoft FTP / TCP 22
idp – Custom IDP / TCP 443, 8443
solr – Custom Search application / TCP 8983
Standard ports are used by the infrastructure services
All the six applications in all environments are available on port 443 (HTTPS) to all users.
Currently IP security isn’t enabled. Anyone can change / spoof the IP address of a workload VM and can still have access to the
network.

Reviewing the customer requirements

Below were the initial requirements from the fictitious customer, Corp-XYZ with respect to the microsegmentation design:

Create security boundaries (ring-fence) for the prod and non-prod environments
Achieve zone level segmentation for the non-prod environments, viz Test, Dev, UAT, QA and Staging. These environments don’t need
microsegmentation.
https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 5/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Achieve micro-segmentation for the Prod environment. Create security boundaries for applications and app-tiers
Secure management access to workloads across all environments
Secure IP Security for workload VMs. Prevent IP address changes on workloads without admin approval.
Achieve dynamic security policies whenever applications / environments are scaled out.
Allow only TLS 1.2 and above for HTTPS access to the applications in all environments.
Develop a quick way to lock down an environment in case of emergency.

Generating application interdependency sketch

Application interdependency sketch and details will mostly come from the respective app owners from the customer side. Let’s assume
we have developed one for the customer, Corp-XYZ based on the collected information. The below sketch shows the service interdepen‐
dency across tiers for the six applications under the production environment. Currently this is unsecured and with the microsegmentation
design which we develop in the next section, we will secure these production applications.

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 6/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 7/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Designing the microsegmentation architecture

Below are the design decisions for developing the microsegmentation design for the fictitious customer, Corp-XYZ:

The design will be a zero-trust model. This means there will be a default policy rule with “deny-all”. Anything that needs to be permit‐
ted should have an allow rule defined in the policy.
We will organize the security rules based on categories and the rules will be evaluated from left to right in the policy UI. As such we
will have policies for
Emergency – To lockdown an environment in case of security compromise
Infrastructure – To define rules for access to infrastructure components
Environment – To define rules for security zone boundaries
Application – More specific rules to define application and app-tiers
For each rule, we will make more specific selection in the rule’s “Applied To” field instead of the wider DFW scope.
Security zones will be defined based on dynamic group membership using tags. We will map security zones to environments. As such
we will have the below security zones:
Security zone – Dev
Security zone – Test
Security zone – UAT
Security zone – QA
Security zone – Staging
Security zone – Prod
We will define broader security groups like “All_Workloads” statically using IP Subnets / Segments for simplicity
We will reduce group nesting (if possible, avoid) for management simplicity
We will always use tag match condition as “Equals-to” while defining security group membership to avoid any false membership
We will define tags with both scope and tag fields to better organize the tags (key and value)
We will use multiple tags combination using the logical AND operator to precisely match environments, applications or app-tiers. We
will avoid using combined tags and other match conditions like “starts-with” etc to avoid management complexity.
We will define a policy called “Allow_Admin_Stations “ which will allow the security group for admin stations with management ac‐
cess to all the workloads.
We will define infrastructure policies for environments for access to infrastructure components like AD, DNS, DHCP, Backup, SMTP
etc.
As the customer requirement is to have only zone boundaries (and not microsegment) for all non-Prod environments, we will define
environment policies to zone fence Dev, Test, UAT, QA and Staging environments.
We will define environment policies to allow internet access from each environment.

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 8/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Application specific policies will be implemented only for the Prod environment to define inter-app dependency rules and intra-app
communication between app-tiers.
Security fencing for the Prod environment will be around app-tiers and granular rulesets will be in place to allow communication
across different app-tiers within the same application or between applications.
We will define emergency policies to lockdown either specific environments or all environments.
All workload segments will have spoofguard profile enabled to avoid unauthorized IP address changes by users.

Below sketch depicts the security fencing of environments (zones) which will be the desired state for the Dev, Test, UAT, QA and Staging
environments.

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 9/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Prod zone is further fenced / microsegmented at the app-tier level which will be it’s desired state.

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 10/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Now that we developed the microsegmentation architecture, we will convert this microsegmentation architecture to security policies and
rule sets to achieve zero-trust security for the fictitious customer, Corp-XYZ.

Advertisement

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 11/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Achieving the size and shape you

We will cover this in Part 2. Stay tuned.

I hope the article was informative.

Thanks for reading.

Continue reading? Here are the other parts of the series:

Part 2 : https://vxplanet.com/2022/12/06/nsx-microsegmentation-part-2-transforming-architecture-to-policies/

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 12/13
2/1/24, 5:26 PM NSX Microsegmentation Part 1 : Developing the Architecture – VxPlanet

Published by HariKrishnan

View all posts by HariKrishnan

Website Powered by WordPress.com. VxPlanet

https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/ 13/13