The steps detailed in this section are optional and should be implemented based on organizational needs.
Configure Insider Threats & Advanced Compromise Policies
Admins will enable certain standard UEBA policies in addition to enabling the default disabled policies. The following sections describe and explain the circumstances for each case.
Standard UEBA Use Cases
Although, the recommended course of action in the getting started guide is to disable all the standard UEBA policies, some organizations might have a use case that requires a standard UEBA policy. The following is a list of common use cases for standard UEBA.
Identifying traffic from a certain country or list of countries
The “Risky Countries” policy can generate an alert for every access from a country on a watchlist. This can be useful for reviewing activity from countries from which users are not authorized to work.
Identifying data movement to all non-managed app instances
Insider Threats & Advanced Compromise has policies to identify data movement from managed application instances as well as data movement to personal application instances. However, if there is a need to also identify data movement to not only personal but all non-managed app instances, then the “Bulk Upload” policy can be used. This policy requires labeling each managed application instance and adding it to the exception criteria in the policy definition.
Enabling the Default Disabled Policies
There are Insider Threats & Advanced Compromise policies (including “High severity malware alert” and “High severity DLP policy violation”) that come disabled by default. This is because these policies are dependent on account specific policy configurations. The following sections describe the process and conditions for enabling each of these policies.
New private app access for this user
This policy identifies if there are new NPA apps being accessed by an individual. If you are still enabling / adding NPA apps, we recommend this policy stay disabled. Once all the NPA apps have been onboarded, this policy can be safely enabled. Enabling this policy too early may cause a large number of alerts to be raised for newly onboarded applications.
Reduce UCI for DLP policy violations
There are four policies that impact the UCI score depending on the severity of the DLP policy violation.
-
Low Severity DLP policy violation
-
Medium Severity DLP policy violation
-
High Severity DLP policy violation
-
Critical Severity DLP policy violation
The severity of the DLP alert is determined by the thresholds in the DLP profile / rule referenced in the policy violation.
The severity of the policy violation maps to one of the Insider Threats & Advanced Compromise policies, and, based on this you can map the required severity level and tune the desired impact in the Insider Threats & Advanced Compromise policy as shown below. This impact should take into account the expected alert volume to reduce the UCI scores to moderate and poor values only in exceptional cases.
Reduce UCI for Malware & Malsite Policy Violations
There are four malware and one malsite policy to impact the UCI score for policy violations as shown below.
-
Malsite alert
-
Low severity malware alert
-
Medium severity malware alert
-
High severity malware alert
-
Patient zero malware alert
Unlike the DLP policies above, the severity of a Malware alert is determined internally by the threat detection service that raised the alert. However, similar to above, these Insider Threats & Advanced Compromise policies can be enabled and configured to the desired score that does not result in numerous low UCI users.
Reduce UCI for third party app violations
There are four policies that reduce the UCI for strange or malicious behavior detected by third party cloud applications. These are triggered by an app event that is generated from an API connector audit log. Enable these if you need to see the UCI reduced as a result of suspicious behavior detected by upstream sources like Google Drive and Box. You do not need additional configurations for Insider Threats & Advanced Compromise policies.
-
Suspicious activity detected by Google Drive
-
Device compromise detected by Google Drive
-
Device ownership change detected by Google Drive
-
Malicious file detected by Box
Manage Exclusion List
Admins can create a list of users within the same account to exclude from UCI scoring and UBA anomaly incidents.
Use cases for the exclusion list include trusted users (e.g., SOC team) and regular users excluded for compliance with workers’ council requirements in certain countries.
Navigate to Incidents > Insider Threats & Advanced Compromise > All Users > Manage Exclusion List
1.Click Manage Exclusion List and the Exclusion List window opens. Select the users, user groups, or organizational units to exclude or start typing in the field to view a subset of users.
2. Click Save.
3. Optionally, edit your list by selecting it again and making edits to the Exclusion List window.
When a user is added to the exclusion list, their historical data is not purged. The user is removed from the active users list after 48 hours and completely removed after 60 days. An excluded user’s UCI score is set to 1000 for Real-time Protection policies.
You will see the following message at the top of your list page as confirmation.
Exclusion List Audit Log
To view the audit log, navigate to Settings > Administration > Audit Log > +Add Filter > Log Type > User Exclusion List Edited
The audit log captures the first time the exclusion list is created and each time it’s edited.
