Based on the traffic scope that you selected at the time you start a recommendation analysis, the Security Intelligence Recommendation engine selects unmicrosegmented ingress (inbound), egress (outbound), or intra-application traffic flows from and between the compute entities of your specified recommendation boundary.
The Security Intelligence Recommendation engine aggregates the flows by the service (ports or protocol criteria) on which these traffic flows occurred. The sources and destinations for each of the flows for a particular service are grouped together. While creating the grouping, the Security Intelligence Recommendation engine uses the user-specified threshold for matching ratio and attempts to reuse groups that exist in the NSX inventory, including those groups that fall within an existing IPSet range of a group.
If the Security Intelligence Recommendation engine does not find an existing group that can satisfy the set grouping threshold, it creates a new group to recommend.
When generating a recommendation, the Security Intelligence Recommendation engine considers the traffic flow types that you specified in the Traffic to Analyze option. If you selected the incoming traffic flow type, only traffic flows that originate outside of your application boundary are considered. If you selected the traffic flow types of all traffic, incoming and outgoing traffic, or incoming and intra-application traffic, then the Security Intelligence Recommendation engine aggregates the traffic flows in those directions together to form the DFW rule recommendation, based on the service.
Take the following flows, for example.
Boundary is set using VM1 and VM2
Groups: CG with VM1 and VM2 as members
Groups: G3 with VM3 and VM4 as members
Assuming Match threshold : 50%
The unsegmented traffic flows are as follows.
VM3 to VM1 using SSH
VM1 to VM2 using SSH
The following is the resulting microsegmentation recommendation, which is a single rule for SSH.
Source Group |
Destination Group |
Service |
Applied-to Group |
|---|---|---|---|
G3 + CG (existing groups reused) |
CG with VM1, VM2 as members |
SSH |
Group CG with VM1 and VM2 as members |
If the traffic flows are originating from outside the configured mask of private IP addresses, then the flows from and to such IP addresses that are not included in the private IP prefix list will be marked as “ANY”.
Consider the following unsegmented flows.
ANY external source to VM1 using SSH
Flows from VM1 to VM3 using SSH
Boundary is set using VM1 and VM2
Group defined is CG with VM1 and VM2 as members
In this case, SSH flows are aggregated from ANY (including external sources) to VM1/VM3.
This in turn results in the following microsegmentation rule.
Source |
Destination |
Service |
Applied To |
|---|---|---|---|
ANY |
[VM1] in CG, [VM3] in G3 |
SSH |
CG [VM1, VM2] |
All the rules are always applied only to the members of the recommendation boundary that you had specified before generating the recommendation. The reason aggregation is used is to reduce the number of DFW rules that would result based on the service.
Recommendation for existing DFW sections
If the entities that you selected in the recommendation's boundary scope are associated with any existing distributed firewall sections and you selected the Use Existing Section option in the Select Distributed FW Section dialog box, the Security Intelligence Recommendation engine includes those existing DFW sections when performing the recommendation analysis. The DFW recommendations involve updating the source and destination fields of existing rules to properly microsegment any leaked flows to and from the compute workloads that matched the scope of the specified DFW section.
Previously, the support only provided an update to existing L4 rules in the existing DFW sections. Beginning with Security Intelligence 4.1.1, support is also available to update existing L7 rules in the existing DFW sections associated with the entities in the recommendation boundary scope that you specified.
To use this new feature, you must select the L7 Context Profiles option in the Recommendation Service Type section of the Start New Recommendation dialog box.
- All the existing rules are used to match the leaked flows and the Security Intelligence Recommendation engine attempts to match those flows with the same port, protocol and app_id values in the rules. Sampling the flows with a non-zero app_id is retained as part of the leaked flows. The samplings of flows with app_id value that equals 0 or is empty are filtered out.
- Rules are used when their sources or destinations match. The preference is to use rules with only one side that needs to be updated. If none is found, then, rules that need to have both the source and destination updated are selected.
- For those flows having an app_id value, if an existing rule is matched and picked, the L7 rule is used.
- For those flows that do not have an app_id value, if an existing rule is matched and picked, then the rule must not contain any context profiles. The Security Intelligence Recommendation job only changes the sources and destinations in this rule.
- If there are no existing rules found, a new rule is created.
- For flows that have an app_id value, a new rule is created that contains the context profiles, if the context profile detail can be identified using the app_id value associated with the flow. Otherwise, a new L4 rule is created because the Security Intelligence Recommendation engine does not create new context profiles.
- For flows that do not have an app_id value, the Security Intelligence Recommendation engine creates a new L4 rule that matches the flows.
- If the Security Intelligence Recommendation engine finds an existing rule that needs modification (that is, a matching source/destination side are found), the non-matching side is modified to include the groups (new or reused) containing the computes for which the leaked flows are detected.
- The non-matching side of a rule is modified to include the groups based on the following selection criteria:
- A group is selected by looking for the maximal match of the leaked VMs. It might be a partial match where the group might include other computes not involved in the flows. Multiple groups might be picked. Groups are picked by highest match ratio, then most match count, then the latest create time (those created more recently are prioritized), until no more groups can be picked, or all leaks are covered.
- If the compute entities are not associated with any groups, then a new group is created to accommodate those compute entities. New groups are created for compute entities even if the compute entities are present in existing groups, if the match ratio is less than the group reuse threshold specified.
- A rule is modified to include the selected groups in the sources or destinations.
- If there are no leaked flows detected, which means the current existing rules cover all of the traffic flows during the selected time period, then no new DFW rule is recommended.
- If an existing DFW rule needs to be modified and it is an L7 rule that contains context profiles, the context profiles are retained in this DFW rule.
If the DFW section provided as input already has a lot of rules, and new DFW rules being recommended can exceed the 1000 limit of rules per section, then, the Security Intelligence Recommendation job status is set to FAILED. As a result, the DFW rule recommendation can not be published. You have to provide a section that has sufficient room for the recommended rules to be added to it.
