Rule-Based Policies

To access the Rule-Based policy page, go to Policies > Insider Threats & Advanced Compromise > Rule-Based tab.

Filtering the Policy View

Use the left side panel to filter your policy view. The default view displays all policies and severity types.

Compromised Account Detection Using IP threat Intel

Use Advanced UEBA to detect cases of compromised credentials (CASB API, API Connector). The system finds source IP addresses in app events that match malicious or Tor IPs. This will help find compromised users that need their credentials reset.

Use Advanced UEBA to detect cases of compromised devices (Transaction logs). The system finds destination IP addresses in transactions that match malicious or Tor IPs. This will help find devices that are compromised and need to be remediated.

Editing a Policy

To edit the policy, select the tile and click the pencil icon to open the Configure Policy window. Not all rules can be edited, deleted, or cloned.

After you make your changes you will see an important icon (image above #1). This will remain visible until you apply your changes (image above #3).

Optionally, you can revert your changes (image above #2). You will see the following dialog box.

For the rule-based policies above, you can include or exclude certain users, user groups, or organizational units from the policy.

Custom Rule-Based Policies

Click the dropdown to create a rule-based policy. You can create a new policy or create a policy from the template library.

New from Template Custom Rule Policies

The template library contains the following templates for the new behavior analytics custom rule-based policies for potential suspicious activity. You can change any option once you select a template. The right panel edit window opens to enable editing.

Policies are defined using a set of variables. These variables define the criteria for detecting policy violations. Specify the match criteria for the activity sequence that you want to be alerted on. Each sequence is defined based on a single user, group, organizational unit, and app. All match criteria are ‘And’ed.

To create a new custom rule policy:

Troubleshooting

Suspicious Data Movement Alert Not Triggered for Data Movement Between Instances of the Same Cloud Storage Application

Symptom

The Suspicious Data Movement alert doesn’t fire when a user downloads data from one instance of a cloud storage application (such as Box, Google Drive, or OneDrive) and uploads it to a different instance of the same application—even when the source instance is tagged as Sanctioned.

Cause

By default, the Suspicious Data Movement policy evaluates data movement from sanctioned applications to unsanctioned destinations. When data moves between two instances of the same application, the policy may not trigger because the source instance isn’t explicitly included in the policy’s evaluation scope. Without specifying the source app instances in the policy’s Additional Criteria, the system doesn’t recognize the cross-instance transfer as a suspicious data movement event.

Resolution

To ensure the Suspicious Data Movement alert triggers for data movement between different instances of the same cloud storage application, add the sanctioned source app instances to the policy configuration.

To configure the policy:

1. Navigate to Policies > Insider Threats & Advanced Compromise > Rule-Based tab.

2. Locate the Suspicious Data Movement policy and click the pencil icon to edit it.

3. In the Configure Policy panel, go to Additional Criteria > App.

4. Under App Instances, add the sanctioned source app instance or instances from which data is being downloaded.

5. Click Save, then click Apply Changes on the Rule-Based Policies page.

The policy now evaluates download activity from the specified instances and triggers a Suspicious Data Movement alert when data is subsequently uploaded to a different instance of the same application.

Suspicious Data Movement Policy when App Instance is Added as an Exception

This section describes how a Suspicious Data Movement policy behaves when a specific App Instance ID is added as an exception.

Background / Observed Behavior

Customer scenario:

• Suspicious Data Movement alerts were initially generating as expected.
• Customer created an App Instance with ID 3XXXXXXX38.
• They then added this App Instance as an exception in the Suspicious Data Movement policy.
• This policy change was made on a specific date and noted (evening).
• After this change, no Suspicious Data Movement alerts were triggered.
• Incident history shows alerts up to the specific, and none after the evening policy change.
• The following day, the customer reverted the configuration (removed the App Instance exception).
• After the rollback on the following day, Suspicious Data Movement incidents started generating again.

Technical Explanation

When the customer marks App Instance ID 3XXXXXXX38 as an exception in the Suspicious Data Movement policy, the effective logic becomes:

• Treat only App Instance ID 3XXXXXXX38 (and any other instances added to this exception list) as unsanctioned applications for the purpose of this policy.
• For the policy to trigger:
  • The download must be from a sanctioned application / instance (in the Include list), and
  • The upload must be specifically to App Instance ID 3XXXXXXX38 (or another app instance added to this exception list).

If user activity does not match this exact pattern, the policy will not match, and no Suspicious Data Movement incidents will be generated—even though the policy configuration is syntactically valid.