This brief technical document explains what the user can query for and how the system interprets Layer 7 path queries that contain user-groups and user-ids. The document also exposes possible shortcomings in this first implementation.
The main goal of the initial development phase is "to provide visibility into whether and how a user-group (or a set of user-groups) can access a specific resource".
It is going to become clear in the document why the goal of the initial phase is articulated in this specific way.
In the initial phase of development, Forward does not perform the mapping of user-group/ids to IP source addresses and as such it is unaware of the user groups an IP source belongs to. This means that Forward Enterprise relies on the operator to provide the correct and complete list of user-groups that are of interest for the analysis. The system assumes that the user is not part of any other groups other than those listed in the path query. Note that the system does perform user-id to user-group matching.
Path Query in a Layer 7 Policy Context
Supported Query Types
This section describes examples of supported queries and their semantics. The examples focus on user-groups, but they are applicable to user-ids as well. The focus is on user-group because user-group based policies are far more common than user-id based policies.
The queries below are examples where some optional filters are missing (e.g. Dest L4 Port). They are missing because their presence does not affect the concept being explained in the specific example.
Queries with a single or no user-group
The queries in this section assume that the Forward operator specifies the correct and complete list of user-groups for which he/she is interested in understanding the network behavior.
Generic query that does not specify any user group or user-id
-
Query example: "from IP-X with ip_dest IP-Y delivered”
-
System behavior:
- The system interprets this query as “tell me the paths for the traffic that leave from IP-X, destined towards IP-Y getting delivered”.
- Nothing changes with respect to today’s behavior. If along the path, the traffic matches an ACL containing a user-group clause, the system returns the delivered paths based on the match. This is similar to what happens today when the user does not specify any L4 Destination Ports. In that case, the system shows all the delivered paths with the ability to see the allowed L4 ports in the left filter panel. In this same way, for this query, the filter panel will show the user-groups that allow the traffic to be delivered to the destination for the user to see.
Note: This approach helps the Forward operator gain visibility on which groups have been given access to the destination.
Query that specifies a single user group + a located IP source or subnet
-
Query example: ”from IP-X with user_group A with ip_dest IP-Y delivered”
-
System behavior:
- The system interprets this query as: “tell me the paths for the traffic that leave from IP-X destined to IP-Y,
where IP-X maps to a user that belongs to group A”. The system does not verify whether IP-X belongs to group A,
instead it assumes that the Forward operator is issuing a correct query.
- In case of IP-X being a subnet, the assumption is that a user belonging to group A is present within the IP-X subnet.
- If group A is sufficient to access IP-Y, the system will return the paths the traffic takes to be delivered to IP-Y.
- If group A is denied access to IP-Y, the system will return no results.
- If traffic to IP-Y needs to pass through a rule matching on group B, if group A and B have users in common, the system will show the paths indicating how group A and B are required permissions (in sample packet, and in filters). If group A and B do not have any users in common, then no results will be returned as traffic will not be delivered.
- The system interprets this query as: “tell me the paths for the traffic that leave from IP-X destined to IP-Y,
where IP-X maps to a user that belongs to group A”. The system does not verify whether IP-X belongs to group A,
instead it assumes that the Forward operator is issuing a correct query.
Query that specifies a single user group without specifying the IP source or subnet
-
Query example: “from anywhere with user_group A with ip_dest IP-Y delivered”
- System behavior:
- The system interprets this query as “tell me all the paths that reach IP-Y, whenever a user belongs to group A”.
- The system will trace flows from every edge interface under the hypothesis that the user connected to that interface belongs only to group A. The system does not directly map the user groups and user id to their source IP addresses or subnets. This means that the hypothesis is not verified by the system, it is assumed to be true.
- For this type of “open” queries, the system will run through each located edge subnet and return the first few thousand results. The user can fine tune and filter the results by selecting the entry point from the filter panel (left) or directly adding a specific IP source or subnet to the query as shown above in the example A and B.
- System behavior:
Queries with multiple user-groups
Query that specifies a set of user groups + a located IP source or subnet The system assumes that the specified user groups are ALL the groups the IP source or subnet belong to.
-
Query example: “from IP-X with user_group A,B with ip_dest IP-Y delivered”
-
System behavior:
- The system interprets this query as “tell me the paths for the traffic that leave from IP-X and reaches IP-Y,
where IP-X maps to a user that belongs to both user groups”.
- In case of IP-X being a subnet, the assumption is that the user belonging to A and B is present within IP-X.
- The system will return the paths (if any exists) for the traffic delivered to IP-Y that is sourced from IP-X and
belongs to a user in both groups.
- As an example, if traffic passes through a firewall rule that requires membership in A, and another that requires membership in B, it will be returned as a search result.
- If group A and group B do not have any common members at the time of snapshot collection, then this query returns no results
- The system interprets this query as “tell me the paths for the traffic that leave from IP-X and reaches IP-Y,
where IP-X maps to a user that belongs to both user groups”.
Query that specifies a set of user groups without specifying the IP source or subnet
-
Query example: “from anywhere with user_group X,Y with ip_dest IP-B delivered”
-
System behavior:
- The system interprets this query as “tell me all the paths that reach IP-B, whenever a user belongs to both groups”.
- The system will trace flows from every edge interface under the hypothesis that the user connected to that interface belongs only to group A and B. The system does not directly map the user groups and user id to their source IP addresses or subnets.
- For this type of “open” queries, the system will run through each located edge subnet and return the first few thousand results. The user can fine tune and filter the results by selecting the entry point from the filter panel or directly adding a specific IP source or subnet to the query as shown in the example A and B above.
Queries with incorrect or missing user-groups
Reiterating what expressed above, in the initial phase of development, Forward does not perform the mapping of user-group/ids to IP addresses and as such is unaware of the user groups an IP source belongs to. This means that Forward Enterprise relies on the operator to provide the correct and complete list of user-groups that are of interest for the analysis. This section below explains the possible issues when queries include IP sources accompanied by an incorrect or incomplete list of user-groups.
Case 1
Description:
- IP-X is assigned to a user who belongs to user-group A, B
- Firewall policies require membership to group B to gain access to IP-Y
- Forward operator queries based ONLY on group A: “from IP-X with user-group A with ip_dest IP-Y delivered”
System Behavior:
- In this case, Forward will return no results even if the traffic is actually delivered. This is due to the fact that the system does not perform matching of user-group/ids to IP addresses and as such it is unaware that IP-X belongs also to group B. The Forward Operator can remove the “delivered” clause to understand where and why Forward shows no result.
- The exact query semantic is to return traffic paths for which membership in group A alone is sufficient for traffic to be delivered.
- Note that this query cannot be used to guarantee that group A does not have access to IP-Y. A user belonging to group A might also belong to other groups and therefore have access to IP-Y.
Case 2
Description:
- IP-X is assigned to a user who belongs to user-group A, C
- Firewall policies deny access for members of group C
- Forward operator queries based on ONLY on group A: “from IP-X with user-group A with ip_dest IP-Y delivered”
System Behavior:
- In this case Forward could erroneously return delivered flows when in reality no traffic may be delivered. This could be the case when the firewall deny rule based on group C (missed by the query) is followed by a permit rule based on group A.
- The diagram below shows the group list that needs to be used in the search to refer to users in each part of user-id space.
Case 3
Description:
- IP-X is assigned to a user who belongs to user-group A, C
- Firewall policies require membership to group C to gain access to IP-Y
- Forward operator queries based on group A and B: “from IP-X with user-group A,B with ip_dest IP-Y delivered”
System Behavior:
- In this case, Forward will return no results even if the traffic is actually delivered. Consider a case where A&C is non-empty, but B&C is empty. This means that there is no user that is in A&B&C (belongs to all 3 groups). Because the query is asking for users that are in A&B, if traffic passes through a firewall rule which requires membership to C, then we won’t return any results, since users that are in A&B are not in C.
Queries with user-ids
What explained in the previous sections for user-group is applicable to user-id. The system will support similar queries with user-ids, but it won’t support queries for multiple user-ids at once, i.e. “from IP-X with user_id A,B with ip_dest IP-Y” is not supported. The system also supports queries containing both user-ids and user-groups.