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 security 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 thorough understanding of the customer environment, the applications, it’s locations, services, traffic directions etc. This information is captured 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 environment. In Part 2, we will transform the developed design to DFW rules to achieve zero-trust security.

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
  • 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
• 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.
• 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 interdependency 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.

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 permitted 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 access 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.
• 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.

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

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.

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/