Data Loss Prevention

Hello everyone, we're rolling out version 14.6.  In our testing we hit the ceiling for the default value of 10,000 for the setting - IncidentDetection.MaxIncidentsPerPolicy.  The first thing that came to mind was this setting is designed to prohibit a runaway policy.  For Discover scans we plan to limit incidents via the Target properties because we experienced a misconfigured policy that maxed out our DB but we have no idea how many incidents we'll see in the DIM world. We'll have to activate policies slowly and monitor incident volume I guess.

Has anyone had to adjust the default setting for IncidentDetection.MaxIncidentsPerPolicy?

What about it's companion setting "IncidentDetection.IncidentLimitResetTime"? 

I'm thinking there should be no performance impact to Symantec detection servers since the content inspection will continue regardless but no incidents for the policy in question will be generated.  It's the backend database we need to be concerned with and we have the proper monitoring/alerts in place for that.

Thanks in advance.

hello

 If you are sure it is normal for you to have this amount of incidents per policy you can increase the number of incident per policy threshold(IncidentDetection.MaxIncidentsPerPolicy) or decrease IncidentDetection.IncidentLimitResetTime (per default it should be 1 day (not sure of this) so you could decrease it to 1 hour (in ms)) and policies will be inactivated only if number of incident threshold is reached in 1 hour. dont set it too low as it will add some operations to detection server (e.g. dont set it to 1ms).

 You could also split your policy into several policies (depending on current content of your policy).

 regards

To add to the discussion, what is your policy maturity? I ask since if you're hitting the daily limit of 10,000 incidents in 24 hours then hopefully you will be at a more mature level where you are generating incidents but they are being handled automatically. Usually generating that many incidents becomes something your remediation team is unable to process so policy tuning becomes a necessary side effect. For data at rest in particular 90% of the issue is in 10% of the files. Given that risk spread many cusotmers have higher thresholds for incident generation on DAR then they do on other channels. DAR is far more likely to hit the limit than other channels since incidents tend to be concentrated. Endpoint DAR in this case is the most intensive since you could have 30,000 endpoints scanning that each generate an incident which then rolls up to a large number of incidents while each endpoint is minimal risk.

Thanks for the feedback guys. It validates the plan of action we are thinking.  We'll definitely need to address network DAR (no endpoint DAR here) either via the server setting and/or Target options.

For DIM/DIU we'll need to get a baseline first before establishing a threshold.  We're also considering using Splunk or DB monitoring tools to alert prior to automated responses by the system.