How to Optimize NGL Queries with Resource Filtering?

When the conditional checks defined in the should-have and should-not-have expressions of an NGL query are evaluated, the checks are evaluated against all resources matching the specified primary resource type. To optimize the query and improve performance by focusing on the most relevant resources, you can use the where expression.

The where expression allows you to filter resources before applying conditional checks defined in the should-have and should-not-have expressions. By limiting the evaluation to only the most relevant resources, you can reduce unnecessary computations and speed up your NGL’s performance.

Syntax
```
<app suite> <resource type> should-have/should-not-have <condition> where <scoped condition>
```
Sample Use case

Create an NGL query to search SSPM for all Azure AD users with Multi-Factor Authentication (MFA) capability enabled, where the users are active and non-guests

Solution
1. Identify the syntax components
  - App suite = AzureAD
  - Primary resource type = User. Check DOM files to learn more.
  - Expression = should-have
  - Condition = check if the account is MFA capable in the User Registration Details
2. Create a base query as per the syntax.
```
AzureAD User should-have userRegistrationDetails with-attribute {isMfaCapable = true}
```
3. To limit the query to execute only for active and non-guest users, update the query with the where expression. As per the AzureAD DOM file, accountEnabled and userType attribute will determine if the user is active and a guest, respectively.
```
AzureAD User should-have userRegistrationDetails with-attribute {isMfaCapable = true}
where accountEnabled = true and userType != "Guest"
```
  The where expression in this NGL query first selects only the relevant users by applying the condition specified. This means that only active, non-guest users are considered further in the evaluation process. Next, the should-have expression is evaluated on this smaller subset of relevant users to check if Multi-Factor Authentication (MFA) is enabled for each user.

Technical Considerations

Using the where expression properly requires understanding its details. Below are some important points to understand.

Two-Step Execution Process – The where expression scopes the conditions for the NGL rule, which follows a two-step process:
- Resource Filtering: Resources are filtered based on the scoping conditions defined in the where expression.
- Evaluation: After resource filtering, the evaluation is performed using the conditions specified in the should-have or should-not-have expression.
Impact of should-have/should-not-have Expressions
- These expressions only apply to the specific condition that directly follows them.
- They do not affect the scoped condition defined in the where expression.
Secondary Resource Usage – When a secondary resource with scoping conditions is involved, it should be used with should-have.

Example:
```
AzureAD User should-have userRegistrationDetails with-attribute {  

    isMfaRegistered = true  }  

where groupmember with-attribute {  

    group with-attribute {  

        displayName = "ABC_INACTIVE_USERS"   }  }  

and accountEnabled = true and userType != "Guest"
```
In this rule:
- The primary intention is to generate findings for non-guest users with enabled accounts.
- A scoping condition is applied to the secondary resource (Group), connected to the primary resource (User) via GroupMember.
- However, the connection between a User and a Group (e.g., ABC_INACTIVE_USERS) must be explicitly stated in the should-have expression for clarity.
Unmatched where expression in NGL – If an NGL rule uses a where expression that does not match any resource, the rule execution will not produce any findings.

Limitations

Filtering Primary Resources Based on Secondary Resource Conditions: The where expression does not directly support filtering primary resources solely based on conditions applied to secondary resources.

Example: Generating evaluation results for AzureAD users who belong to a specific group, such as group XYZ, is not possible. Scoping conditions on secondary resources are solely intended to narrow the search scope, improving evaluation performance by excluding irrelevant secondary resources. However, this does not impact the evaluation of primary resources, all primary resources are still evaluated. To limit the evaluation of primary resources, scoping conditions must be applied directly to the primary resource type.

AzureAD User should-have any groupmember as g with-attribute {
  group exists
}
and userRegistrationDetails with-attribute { isMfaRegistered = true }
where groupmember with-attribute {
  group with-attribute { displayName = "XYZ" }
}

In this case, although the scope is narrowed to the group XYZ, the rule still evaluates all AzureAD users. Any user resource which is not connected to the XYZ group or does not have MFA registered will generate a failed finding.

Syntax

Sample Use case

Solution

Technical Considerations

Limitations

References