Security Intelligence (formerly NSX Intelligence) is a powerful tool to visualize the security posture of the workloads and gather information about their flow insights in the NSX environment. Security Intelligence is hosted on NSX Application Platform (NAPP), and one of the pre-requisites to activate Security Intelligence is to have a successful NAPP deployment in place. I hope you might have already checked out my previous articles on NAPP, if not I strongly recommend doing so before proceeding with this article.
Security Intelligence offers the below capabilities:
- Graphical visualization of the security posture using the traffic flow information from the workloads.
- Generate recommendations for DFW rules, services and security groups to assist with microsegmentation planning for applications.
- Suspicious traffic detection to / from the workloads.
Our focus for this five-part blog series is on the first two capabilities – visualization and microsegmentation recommendations, and here is the breakdown:
Part 1: Developing the microsegmentation architecture
Part 2: Generating microsegmentation recommendations
Part 3: Workload classifications
Part 4: Flow Direction aware Policies
Part 5: Handling broad-match rules
ICYMI few months ago, I wrote a two part blog series on NSX microsegmentation for a fictitious customer Corp-XYZ, but that was completely a manual approach and required complete information from the customer about the applications, application tiers and the necessary services, which might not be the ideal case for all customers. Often, we require tools like Security Intelligence or Aria Operations for Networks (formerly VRNI) to identify flow information of the applications and review them to make whitelisting decisions prior to developing the microsegmentation architecture. If you’d like to check out the manual approach, here are the links:
Part 1 : Developing the architecture
https://vxplanet.com/2022/11/30/nsx-microsegmentation-part-1-developing-the-architecture/
Part 2 : Transforming architecture to policies
https://vxplanet.com/2022/12/06/nsx-microsegmentation-part-2-transforming-architecture-to-policies/
Let’s get started by developing a microsegmentation architecture for a fictitious customer VxCorp (who is an e-commerce company) using NSX Security Intelligence.
Table of Contents
Understanding the application and microsegmentation requirements
After the requirement gathering workshops with the fictitious customer VxCorp, we have the below details about the application that needs to be protected (microsegmented):
- The application to protect is the e-commerce website that is hosted on the prod environment. This e-commerce website is a platform for VxCorp’s customers to buy or sell goods online.
- The e-commerce website has six application tiers, they are:
- web-tier – front facing web component
- db-tier – database component
- search-tier – offers search functionality for the website
- news-tier – displays current offers and promotions
- idp-tier – allows two-factor authentication for customers
- log-tier – allows logging of customer activities
- Each application tier is composed of two virtual machines
- All application tier VMs are currently hosted on a single network (same distributed port group in vCenter) and don’t have any traffic filtering enabled.
- Customer doesn’t have information about the internal ports / services accessed between the application tiers.
- The e-commerce website is accessible only over HTTPS
- The application tier VMs are managed via HTTPS, SSH and RDP.
- All the application tier VMs talk to same infrastructure services
We have captured the below requirements with respect to the microsegmentation design:
- Allow client traffic to the application only on port TCP 443.
- Allow only specific ports / services between the application tiers (inter-tier)
- Allow only specific ports / services within each application tier (intra-tier)
- Allow management access to the application tiers from specific admin stations
- Allow management access to the application tiers only on ports TCP 443, 22 and 3389
- Allow access to infrastructure services from all application tiers.
- Configure L4 firewall rules. L7 or context-aware rules will be a future scope.
- Drop anything to / from the application that isn’t explicitly allowed.
Now at this moment, based on the information gathered about the application and the microsegmentation requirements, a draft version of the application architecture looks like the below.
This architecture currently has many missing elements, and our objective is to get this completed after analyzing the traffic flows in the subsequent sections.
Analyzing the application traffic flows using Security Intelligence
Our current application architecture is incomplete as it doesn’t have information about the intra-tier and inter-tier ports and services. We will capture this information by analyzing the traffic flows for each of the application tiers, get this information reviewed by the application owners of VxCorp and whitelist only the services that are required. Let’s do that now:
- Creating application security boundaries
As we have the information about VMs that make up each of the application tiers, we will create security groups for the same to analyze the traffic flow. The below VMs in the NSX inventory make up the respective tiers in our e-commerce application.
Let’s create tags for defining group memberships. We will consider the approach of using multiple tags with logical AND operation to define group membership criteria (for better manageability).
We have the below security groups created for application, application tiers and infrastructure services.
Below is the membership criteria for the e-commerce application. As stated above, we use the approach of multiple tags to match the application VMs.
Below is the membership criteria for an application tier based on multiple tags.
and below is the membership criteria for an infrastructure service.
Note : It’s always better to create security groups prior to analyzing the flows and running Security recommendations (as long as we have the information), as it can reuse any existing groups that are available and makes visualization and analysis easier. However, it’s not mandatory to have the groups pre-created and recommendations can suggest security groups based on the analyzed traffic flows.
At this moment, we have the security boundaries created around the application and application tiers. Now let’s enable flow collection on the vSphere cluster.
- Enabling flow collection for the vSphere clusters
Let’s connect to the NSX Application Platform dashboard and confirm that Security Intelligence is activated, platform is healthy and that we don’t have any open alarms.
We will now enable traffic flow collection on the vSphere cluster where the application is hosted.
Let’s confirm that we have all our internal IP networks included in the private IP ranges list. Any IP addresses not included in this range will be marked as “External” in the Security Intelligence visualization dashboard.
Now let’s navigate to the Security Intelligence Visualization dashboard under “Plan & Troubleshoot” -> “Discover & Take Action” and change the view to “All Groups”. We see “Unprotected” flows (red dotted lines) between the groups because we don’t have any security policies or rules configured and all the flows are hitting the default ANY <-> ANY rule.
We also see three system created groups:
- Uncategorized Computes : This group has VMs that are not part of any security groups
- Unknown : This group contains IP addresses that are included in the private IP ranges but a compute object is not found in NSX.
- External : This group contains IP addresses that are not included in the private IP ranges.
We will now take an hour break to allow enough flow information to be gathered, and once we resume, we will have enough data to start the analysis. Meanwhile, if you would like to offer me a drink, here is the link:
Okay, it’s nearly an hour now. Let’s start the analysis.
- Analyzing the flows for web tier
Let’s analyze the flows for the web tier. Since we already categorized VMs to their respective application tiers, flow details will show up the group information for each source and destination VM, and this helps to speed up our analysis.
After reviewing the flow details, we will summarize it to a table of what we assume to be legitimate traffic.
We will now repeat the process for all the remaining application tiers.
- Analyzing the flows for search tier
- Analyzing the flows for news tier
- Analyzing the flows for DB tier
- Analyzing the flows for IDP tier
- Analyzing the flows for log tier
Now that we completed the analysis, we will review the summarized flow details for each application tiers with the application owners of VxCorp to make whitelisting / blacklisting decisions.
Developing the application microsegmentation architecture
Post review of the flow information with the customer, and after we have filtered out the irrelevant entries, we will now consolidate flow details of all the tiers into a single table which can be used to complete the missing information in the application architecture that we created earlier. Below is the consolidated flow information, which in other words, is our desired DFW policy ruleset.
and below is the completed logical sketch of the e-commerce application architecture. Note that this has all the missing information populated including ports / services and new flow directions which we discovered during analysis.
Optionally, we can create a new Security Intelligence visualization view to reflect the logical architecture we just built. We will switch the view to “Computes”, assign labels to VMs based on their application tier membership and then switch to clustered mode with labels. This step is optional but can be used as a supporting artifact during conversations with VxCorp. To understand how to use labels for visualization, please check out the official VMware documentation below:
https://docs.vmware.com/en/VMware-NSX-Intelligence/4.2/user-guide/GUID-FDD2C24D-0D90-4159-A020-E5B6781D83A6.html
The view looks like the below:
and FINALLY combining the logical application architecture we just built with the microsegmentation requirements that we discussed at the beginning, will give us the desired microsegmentation architecture for the e-commerce application. See that our desired architecture has security fencing around each application tier VM as an initial step to achieving VxCorp’s vision of zero-trust lateral security.
We will use this as a blueprint to assist with microsegmenting our e-commerce application in the subsequent chapters of this blog series.
Stay tuned!!!
I hope the article was informative. Thanks for reading.
Continue reading? Here are the other parts of this series:
Part 2: Generating flow recommendations
https://vxplanet.com/2024/09/19/microsegmentation-using-nsx-security-intelligence-part-2-policy-recommendations/
Part 3: Workload Classifications
https://vxplanet.com/2024/09/19/microsegmentation-using-nsx-security-intelligence-part-3-workload-classifications/
Part 4: Flow direction-aware rules
https://vxplanet.com/2024/09/21/microsegmentation-using-nsx-security-intelligence-part-4-flow-direction-aware-rules/
Part 5: Handling broad-match rules
https://vxplanet.com/2024/09/22/microsegmentation-using-nsx-security-intelligence-part-5-handling-broadmatch-rules/
