Welcome to Part 2 of the microsegmentation blog series using NSX Security Intelligence. In the previous article, we conducted workshops with the fictitious customer VxCorp, gathered their application microsegmentation requirements, performed flow analysis using NSX Security Intelligence and developed the microsegmentation architecture for the application. In this article, we will run Security Intelligence recommendations on the analyzed traffic flows and fine-tune it with the architecture blueprint that we developed previously, to arrive at the desired policy structure based on VxCorp’s requirements. If you were not following along, I highly recommend reading Part 1 first before proceeding with this article:
Part 1 : Developing the architecture
https://vxplanet.com/2024/09/05/microsegmentation-using-nsx-security-intelligence-part-1-developing-the-architecture/
Let’s get started:
Table of Contents
Considerations while running Security Intelligence Recommendations
- Security Policy recommendations are generated for the Application Category in DFW. During analysis, if we identify any rules that are intended to be in other categories (like Infrastructure and Environment), they need to be created manually outside of the Security Intelligence workflow.
- Policy recommendations are generated only for unprotected traffic. Unprotected traffic refers to flows that hit a DFW rule with both source and destination fields set to ANY (irrespective of the scope where the rule is applied). Starting with NSX Security Intelligence version 4.1.1, we have an option to specify additional rules (mainly, broader rules) to consider while generating flow recommendations. ie, we are generating more granular rules from a broader existing DFW rule using the recommendations workflow.
- Recommendations workflow creates a new policy section for the application in DFW. The application here refers to the security group specified as ‘Input Entities’ while running the recommendation workflow, which is also known as the recommendation boundary. We can also target the recommendation output to an existing DFW policy section, provided this policy is under the application category and has the scope set to the recommendation boundary.
- In the recommendation output, all the recommended rules are aggregated based on services. For example, in a scenario where we have flows for a specific service (HTTPS) between VMs in the recommendation boundary (both intra-tier and inter-tier) as well as inbound to the recommendation boundary, and with the default options in the recommendation workflow, we see a single rule for this HTTPS service that aggregates all the source and destination fields. This must be carefully reviewed, as this can open broader rules that can allow unintended communication. I believe the reason for aggregation is to prevent hitting the limit of 1000 rules per DFW policy.
- Starting NSX Security Intelligence 4.1.2, we have the option to generate flow direction-aware rules that can recommend more granular rules for a specific service based on the flow direction to / within the recommendation boundary. We will cover this in more detail in Part 4.
- Recommendations workflow can optionally define a connectivity strategy for the default rule of the policy. The connectivity strategy could be a default Allowlist rule or a Denylist rule (Source: ANY and destination: ANY with action: ALLOW/DENY) scoped at the recommendation boundary.
Generating Security Intelligence Recommendations
In Part 1, we developed a policy blueprint for the application based on manual flow analysis, as shown below. It’s possible that as we run the recommendation workflow, we might get new rule suggestions that were possibly missed in the manual analysis previously. For those new recommendations, we will need to confirm with VxCorp and whitelist those, if legitimate.
Let’s start a new Security Intelligence Recommendation. Navigate to “Plan & Troubleshoot” -> Discover & Plan -> Recommendations -> Start New Recommendation.
The field “Selected Entities in Scope” is our recommendation boundary, and this will be our security group defining the application “e-commerce website”. Policy and rule recommendations are generated only for computes within the recommendation boundary.
We will go with the default settings under the Advanced Options for this recommendation job, but let’s discuss the Input and Output settings.
Input Options -> Traffic to Analyze: Our use-case requires “All-Traffic” to be analyzed. However, depending on use-cases, we can generate recommendations based on flow directions – ie, for traffic that is inbound to the recommendation boundary, outbound from the recommendation boundary or between tiers (intra-tier and inter-tier) inside the recommendation boundary.
Input Options -> Protocol and Ports Criteria: It’s possible to exclude protocol and ports from recommendations that have already been flagged as illegitimate during the flow analysis phase earlier. For our recommendation job, we will run it with all ports and protocols included.
Input Options -> Exclude Infrastructure Workloads: It’s possible to exclude workloads that are classified as Infrastructure, so that the workflow will not give recommendations for infrastructure traffic. Ideally the rules for Infrastructure will need to go under the “Infrastructure” category. For our recommendation job, we will consider infrastructure traffic also, in order to identify any missing rules for the infrastructure category. We will explore more on this setting in Part 3.
Input Options -> Additional Rules to Consider: All flows hitting the rules specified in this field will be considered as unsegmented and recommendations will be generated for these flows. The purpose of this option is to segment a broader rule to more granular rules, and eventually get rid of the broader rule. As we don’t have any existing rules in place, we will skip this in our recommendation job.
Output Options -> Default Rule: This setting defines the connectivity strategy for the default rule of the policy. The connectivity strategy could be a default Allowlist rule or a Denylist rule (Source: ANY and destination: ANY with action: ALLOW/DENY) scoped at the recommendation boundary. For our recommendation job, we will choose NONE, and will define an allowlist rule while we are about to publish the recommendation in Part 4.
Output Options -> Generate Flow Direction-Aware Rules: Enabling this setting can recommend more granular rules for a specific service based on the flow direction to / within the recommendation boundary. We will cover this in Part 4, and for our current recommendation job, we will set this knob to disabled.
Output Options -> Compute Group Reuse Threshold: This setting defines how aggressively existing compute-based groups can be re-used in the recommendation output. The default value is 80% which means that any groups suggested in the recommendation need to have atleast 80% match on the group membership with an existing group before the existing group can be re-used. A lower value would mean aggressive group re-use and could possibly lead to irrelevant groups being used in the rules. For our current recommendation job, we will set the value to 80%.
Output Options -> Recommendation Service Type: The workflow can suggest both L4 and L7 rules. Based on the requirements we gathered in Part 1, we will go with L4 services.
Okay, now let’s submit the recommendations job.
The job might take some time to complete. Let’s wait.
Once the job succeeds, we can check the recommendations output and review what’s been suggested.
We see that the policy recommendation suggests 14 rules with scope applied to the application security group (our recommendation boundary). Notice that the rules are aggregated based on services. Now let’s analyze the recommendation output and apply human intelligence to fine-tune it to arrive at the desired policy structure based on VxCorp’s requirements.
Reviewing Security Intelligence Recommendations Output
Infrastructure services
Observation: We see Rule-1, Rule-2, Rule-8, Rule-11, Rule-12, Rule-13 and Rule-14 are created for infrastructure services. Since all the application VMs didn’t have flows with the infrastructure services during the analyzed time interval, we see some newer groups are suggested.
Action: We will clear off group recommendations for the infrastructure services and update the rules with the application security group. We will also rename the rules with a naming standard suggested by VxCorp. This is the updated rulesets for infrastructure services.
Intra-tier and Inter-tier communication
Observation: We see that intra-tier and inter-tier rules are all aggregated based on services. Rule-3, Rule-4, Rule-5, Rule-6 and Rule-7 are created for the same. Look at Rule-6, we see that news tier is allowed to communicate with idp tier due to rule aggregation, which is unintended and was not whitelisted by VxCorp in our architecture.
Action: We will split the aggregated rules as Intra-tier and Inter-tier rules with a naming standard suggested by VxCorp. We will confirm with VxCorp if news tier needs to communicate with idp tier. The updated rulesets look like the below:
Management access to the application
Observation: We see Rule-4, Rule-9 and Rule-10 are created for management access to the application. Since management VMs didn’t have flows with all the application VMs during the analyzed time interval, we see some newer groups are suggested.
Action: We will create a single rule for management access to the application with all the management protocols aggregated. We will also clear off any new group recommendations.
Client access to the application
Observation: The aggregated rule, Rule-4 has an IP group in the source to allow client HTTPS access to the application. If we closely examine the rule, it has also allowed clients to access the IDP tier which is unintended and was not whitelisted by VxCorp in our architecture. Rule-4 is a topic of detailed discussion in Part 4 where we discuss flow direction-aware rules to generate more granular rules based on flow direction.
Action: We will create a single rule to allow clients to access the frontend web tier. We will also clear off any new group recommendations.
Okay, we have now reviewed the Security Intelligence recommendation output for the e-commerce application, and clicking on Proceed will publish the policy to DFW.
But do you think we are good to publish the policy? Answer is No, because the policy will be published to the Application category in DFW. We have Infrastructure rules that need to go the Infrastructure category in DFW, and we need to do this as a workflow outside of Security Intelligence (manual or API based). Let’s do that in Part 3, stay tuned!!!
Thank you for your patience, I know this was a bit lengthier article, but I hope this was informative.
Thanks for reading.
Continue reading? Here are the other parts of this blog series:
Part 1 : Developing the architecture
https://vxplanet.com/2024/09/05/microsegmentation-using-nsx-security-intelligence-part-1-developing-the-architecture/
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/
