Configure ICA to not calculate risk scores for certain policies or users

Products

• Information Centric Analytics

Issue/Introduction

Symantec Data Loss Prevention (DLP) policies can be configured to use imported user risk scores from Information Centric Analytics (ICA) as a contextual attribute in policy detection rules. From the Introducing Contextual Attributes for User Risk Scores section of the Symantec DLP Help Center:

"The User Risk Score context match condition allows you to configure a detection rule based on user risk scores. For example, you can create a policy detection rule that includes the User Risk Score condition. The condition can specify that the detection rule applies to incidents that list a user risk score that exceeds a specified threshold."

In reviewing incidents generated by a user, you find that most or all are false positives, but the user is scored in ICA against risk vectors that have been defined in such a way that they include these incidents; consequently, the user's subsequent legitimate actions are blocked by DLP policies that employ the user risk score as a contextual attribute.

Under these conditions, you want to configure ICA in such a way that incidents created against a specific DLP policy or policies are imported from DLP into ICA but are not incorporated into risk score calculations for individual users. You might also want to reset the risk score for certain users in ICA either by overriding the risk score or setting it to 0.

Environment

Version : 6.6 and above

Component : Risk Vectors

Resolution

If you wish to reset a user's risk score to 0, refer to the Risk Score Reset section; otherwise, skip to the Policies and Risk Vectors Overview section.

Risk Score Reset

There are two supported methods for resetting risk scores. Regardless of the method used, disable the risk vector or vectors the user has been scored against, or filter the risk vector definition(s) in such a way as to preclude the user from being scored again in the future.

1. Purge user records using the built-in stored procedure dbo.spDBA_PurgeEntityData and re-import these user records. Open a support case with Broadcom for assistance with this procedure.
   
   NOTE: If the risk vector or vectors that originally scored the user remain enabled and are not reconfigured to exclude the user(s) in question, the user(s) will be scored again during the same nightly processing run that re-imports them
   
   

2. Change the general portal settings 'Risk Scores Retention Days' and 'Number of days back to use in calculating user risk score ratings' to 1. User scores should revert to 0 after the nightly processing job has run over a couple of days - assuming the user isn't scored against any other risk vectors during that time.
   
   NOTE: If you choose to follow this approach, you will need to restore the original values of these portal settings before resuming normal use

Policies and Risk Vectors Overview

If you find a large number of incidents are false positives, Broadcom's recommendation is to tune your policies in DLP to reduce the number of false positives and modify the scope and criteria of your risk vector definitions in ICA to decrease the likelihood of users being scored for benign behavior.

NOTE: Per section 2.2.3 - Support Exclusions of the Broadcom Software Maintenance Policy Handbook, both DLP policy tuning and ICA risk vector design fall outside the scope of support. If you require assistance with either, Broadcom recommends engaging with professional services.

A risk vector definition should represent a potential threat to an organization and its weighting should take into account both the likelihood of a user's behavior matching its criteria and the potential significance of the impact of such behavior on your organization.

For example, it's common for a user to generate an incident in DLP, so the likelihood of such a thing happening is high; however, the vast majority of incidents represent normal business and don't pose a threat, so their impact is low. A risk vector that is configured to simply score any users who generate data in motion (DIM) incidents in the past 24 hours would be of low value, yet it would cause far more users to be scored than is wanted or needed.

In contrast, a risk vector definition that focuses on a specific policy or group of policies detecting company confidential information would measure a behavior that has a low probability but high impact, making the vector of high value and worth assigning a greater weight than vectors that measure lower impact behaviors.

Methods

The simplest and most effective method to ensure you can import incidents without those incidents influencing users' risk scores would be to modify risk vectors to exclude the policy or policies that generated those incidents. There are a couple of ways to approach this.

The first method is to simply edit each of your risk vectors in the Analyzer by adding a filter to exclude the policy or policies in question. This is a simple and static solution that can be extended to filtering entity collections or even specific users, as needed.

The second and more dynamic method is to create virtual groupings of policies by Loss Impact. In this way, you would work with policies in ICA in a manner similar to Policy Groups in DLP. With different loss impacts defined, you can then create risk vectors that either exclude specific loss impacts or include only certain loss impacts. The following example illustrates this approach:

1. In the Risk Fabric console under Admin > Settings > Data In Motion, create a new Loss Impact you will use to exclude policies from risk calculations:
   

   Name	Do Not Use In Risk
   Description	Do Not Use In Risk
   Value	0

2. Next, assign this Loss Impact to the policies you wish to exclude from risk calculations. This is done on the same page in the console, under the Policies heading.
3. Finally, create or edit a risk vector in the Analyzer to exclude the DIM Loss Potential Value Name dimension value 'Do Not Use In Risk'. Alternatively, you could configure the risk vector to only include specific loss impact types and omit the 'Do Not Use In Risk' loss impact.

For this second method to work, it's necessary to virtually group your policies by assigning them Loss Impacts and either delete any existing risk vectors (creating new risk vectors in the manner described here), or modify the existing vectors to filter on the Loss Impact type.