Welcome to Part 3 of the microsegmentation blog series using NSX Security Intelligence. In the previous article, we ran Security Intelligence recommendations for the e-commerce application, reviewed the recommendations output and modified the rulesets to make it more granular as per VxCorp’s requirements. However, we didn’t publish the policy, as we had infrastructure related rules that needs to go under the infrastructure category in DFW.
In this article we will create all the infrastructure related rules under the Infrastructure category in DFW and discuss Security Intelligence Classifications that is used to classify the workloads as Infrastructure or non-Infrastructure. If you were not following along, here are the links to 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/
Let’s get started:
Table of Contents
Creating the Infrastructure rules
The below rulesets in the recommendations output, meant for application access to infrastructure services (highlighted in blue) and management access to the application (highlighted in red) need to be created under the Infrastructure category in DFW. This can be done either manually or via API. Let’s do this via API:
Below is the json template for the API request body which I will be modifying based on the rulesets that we have in the recommendations output.
Now, to create the policy and rulesets, we will do an API PATCH request with the json contents as the request body against the /api/v1/infra endpoint.
and we can confirm from the UI that the policy and rulesets are created successfully under the Infrastructure category in DFW.
Now that we got the infrastructure rules created, we can go ahead and delete the infrastructure rules from the policy recommendations output.
We are now left with only the intra-tier and inter-tier rules of the application which are ideal to go under the Application category in DFW.
At this moment, we should be all good to publish the recommendations to DFW, but let’s discuss a scenario first before we proceed.
Scenario 1 (Workload Classifications)
So far, we have been working on a greenfield DFW configuration where VxCorp didn’t have any DFW rules in place. Let’s assume a scenario where VxCorp already got the necessary DFW rules in place (as broad-match rules) to allow necessary infrastructure services like the one below.
Since they are broad-match rules with both source and destination fields set to ANY, any traffic hitting these rules will be categorized as Unprotected, and eventually rule recommendations will be generated for these infrastructure traffic as shown below:
To confirm this, let’s review a flow from an application tier VM to an infrastructure service. We see that the flow is categorized as Unprotected as it is hitting rule 3059, which is a broad-match rule to allow Active Directory services and DNS under the Infrastructure category.
Now our objective is to generate rule recommendations with infrastructure workloads excluded, because VxCorp already defined the infrastructure policies in place. We achieve this using Security Intelligence Workload Classification.
Navigate to Plan & Troubleshoot -> Preferences -> Classifications and classify the workloads as “Infrastructure” or “Others (Non-Infrastructure)”.
We have seven infrastructure services available to be classified as “Infrastructure”, let’s do that now:
and we will run the recommendation job with “Exclude Infrastructure Workloads” knob set to Enabled. This is basically an exclusion list for all the workloads that are classified as “Infrastructure”.
Now we have a new recommendation generated that excludes all the infrastructure services and includes only application specific rules that can be published to the Application category in DFW.
Okay, now let’s go back to our original topic where we have the recommendations ready to be published. We have one more interesting scenario to be discussed before we publish the recommendation, and let’s cover that in Part 4. Stay tuned!!!
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 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/
