Microsegmentation using NSX Security Intelligence – Part 4 – Flow Direction Aware Rules

Welcome to Part 4 of the microsegmentation blog series using NSX Security Intelligence. We are currently at a stage where we have all the recommended policy rules fine-tuned as per VxCorp’s requirements, got the necessary infrastructure rules created, and are now ready to publish the recommended application policy and rulesets to DFW.

If you missed the previous articles of this blog series, please check them out below:

Part 1: Developing the architecture
https://vxplanet.com/2024/09/05/microsegmentation-using-nsx-security-intelligence-part-1-developing-the-architecture/

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/

Before we publish the recommendation, let’s discuss a second scenario called flow direction-awareness with respect to the recommendation boundary (which is our e-commerce application).

Let’s get started:

Scenario 2 – Flow direction-aware rules

Remember, we discussed about rule aggregation while reviewing the Security Intelligence recommendations in Part 2. With the default settings, rules are aggregated based on services, and this is true for flows that originate outside the recommendation boundary as well as within the recommendation boundary. The result is that for a given rule recommendation, it’s possible that both the source and destination fields could have compute entities belonging to the recommendation group as well as outside of the recommendation boundary. A good example is Rule-4 which we flagged for detailed discussion in Part 2. Let’s review it again:

This rule handles the below communication for port 443 (HTTPS):

• Intra-tier web to web (within the recommendation boundary)
• Intra-tier idp to idp (within the recommendation boundary)
• Inter-tier web to idp (within the recommendation boundary)
• Admin stations to application (originating outside of recommendation boundary)
• Client access to application (originating outside of recommendation boundary)

Now the effect of rule aggregation without flow direction awareness is that this can open possibilities for broader application access from outside the recommendation boundary in many scenarios.

Our objective is to generate more granular rules based on the flow direction. This means:
– One rule that allows communication within the recommendation boundary, and
– Another rule that handles flows originating outside of the recommendation boundary.

 which looks like the below:

To achieve this, let’s run a recommendation with the toggle button for “Generate Flow Direction-Aware Rules” set to enabled. Basically, with this setting enabled, the source and destination groups for a given rule recommendation will only have membership from compute entities either within the recommendation boundary or outside the recommendation boundary, but not both.

and now if we examine the recommendation output, we see that there is a granular rule (Rule-5) created for traffic originating outside of the recommendation boundary for the same service.

I personally prefer enabling this setting ON, just to make sure we have rule granularity and better control on the indented application access from entities outside of the recommendation boundary.

Okay, now let’s go back to our original topic where we have the recommendations ready. Let’s publish the recommendations now:

Defining the default connectivity strategy for the application

So far, we haven’t created any application specific deny rule to handle blacklisted traffic. If nothing is defined, this traffic will be handled by the default DENY rule at the bottom of the ruleset. Recommendations workflow allows us to set a default connectivity strategy for the policy where we could define an Allowlist or Denylist based on how the microsegmented rules are defined.

In our case, this will be an Allowlist which creates a default ANY <-> ANY drop rule scoped at the policy level.

Now let’s publish the recommendations.

and if we examine the application category in DFW, we see that the policy and rulesets are published.

We also see a default connectivity strategy for the policy, which is the Deny ANY allowlist scoped at the policy level.

At this moment, we are done with the microsegmentation activity for the e-commerce application at VxCorp.

Before we wrap up the blog series, I have one more interesting scenario to discuss and let’s cover that in Part 5.

I hope the article was informative.

Thanks for reading.

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

Part 1: Developing the architecture
https://vxplanet.com/2024/09/05/microsegmentation-using-nsx-security-intelligence-part-1-developing-the-architecture/

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 5: Handling broad-match rules
https://vxplanet.com/2024/09/22/microsegmentation-using-nsx-security-intelligence-part-5-handling-broadmatch-rules/