Microsegmentation using NSX Security Intelligence – Part 5 – Handling Broadmatch Rules

Welcome to the final and Part 5 of the microsegmentation blog series using NSX Security Intelligence. In the previous article, we published the DFW policy and rulesets for the e-commerce application, met the requirements and closed the project with VxCorp. However, there is one more scenario that I would like to discuss before we wrap up this blog series. The scenario is a brownfield DFW environment where VxCorp already got application specific rules for the e-commerce website published as part of other broad-match rules. As such, all the intra-tier and inter-tier traffic for the e-commerce website will be seen as “Protected” and NSX Security Intelligence cannot generate recommendations for already protected traffic. Let’s discuss this in more detail.

If you were not following along, here are the previous articles 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 4: Flow direction-aware rules
https://vxplanet.com/2024/09/21/microsegmentation-using-nsx-security-intelligence-part-4-flow-direction-aware-rules/

Scenario 3 – Handling broad-match rules

As we discussed in Part 2, NSX Security Intelligence can generate recommendation 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).

Consider the scenario below, where VxCorp have already whitelisted communication for the entire production environment, and e-commerce website is one of the applications belonging to the production environment.

The security group “prod_environment” has a broad scope and has the workload VMs of e-commerce website included.

As the rule (Allow_PROD2PROD – 4072) has both the source and destination fields set, any flow hitting this rule will be considered as Protected.

Now let’s run a recommendation job for the e-commerce application and see what happens.

We see the workflow has nothing to recommend (except a management RDP rule).

So how do we generate the microsegmentation rules for the e-commerce application?

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. Now , let’s run a new recommendation with rule ID 4072 (Allow_PROD2PROD) selected to consider for rule recommendation.

We now see that we have the recommendations generated for our e-commerce application, a similar output as we saw in Part 2.

After fine-tuning the rules and working through the whole exercises as described in Part 2, Part 3 and Part 4, we got all the application rules published under the Application category in DFW.

Are we done? The answer is NO.

Why?

If we look at the rule precedence, rules are evaluated from Left to Right in the DFW category. As such, the broad-match rule “Allow_PROD2PROD – 4072” in the Environment category has higher precedence and will be placed on top of any other rules under the application category. Hence no flows will be hitting the rules we just placed under the application category.

Let’s workaround this:

We will create two new rules for the e-commerce application under the Environment category – one for inbound and the other for outbound , and placed just above the broad rule “Allow_PROD2PROD – 4072” with a “Jump to Application “ action, as below. This will skip the broad rule 4072 whenever there is a match condition for the e-commerce application.

Let’s verify the DFW rules applied to one of the VMs in the e-commerce application.

If we analyze the flows for the e-commerce application, we can confirm that the flows are hitting the rules under the application category, thereby meeting our objective.

Okay, let’s wrap up!!! NSX Security Intelligence is one of the powerful tools under the VMware vDefend offerings to accelerate the time to secure applications in the customer’s journey of zero-trust lateral security.

Do check out the official VMware by Broadcom page to see the different lateral security solutions under the vDefend portfolio.

https://www.vmware.com/products/security/vdefend

See you later with a new NSX topic, and don’t forget to share in social media if you find these articles as insightful.

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 4: Flow direction-aware rules
https://vxplanet.com/2024/09/21/microsegmentation-using-nsx-security-intelligence-part-4-flow-direction-aware-rules/