Data Loss Prevention

Is there any mechanism to reprocess incidents in the DB after policy updates?  This would be an extremely useful feature especailly in the early phase of a DLP deployment.  Most customers initially set up DLP and let it run for a while to generate incident data that can be used to fine tune the policies.  It would be fantastic if after adding a bunch of an exceptions, the user could kick off a process that would re-evaluate existing incidents against the updated policy and remove those that no longer match due to the changes.

I'm thinking something along the lines of how you do filters in gmail.  Once you create one there is an option to apply that filter to existing mail rather then just new incoming mail.  This way you can setup a new label and batch move all your mail to the new label based upon a filter.  Something like this would save a lot of man hours.  Today I see customers litterally just wiping all those early pre-tuned incidents rather then digging through them.

Joe

This would be a nice feature.  Also, being able to search incidents by what the matched text would help in this process.  We have a status called False Positive - Policy Changed that we use to mark stuff like this, but it is painful to go back and find all the false positives that you just fixed.

Joe,

Currently there isn't an option to do this with the regular DLP interface. I agree this would likely help in the tuning process of policies to more accurately identify sensitive information. The question I'd ask you though, is would it matter if the false positive were marked as fixed?

I would suggest perhaps working with 2 categories of false positive status (similar to Jsneed approach). 1 is for False Positive - Needs fix, 1 is for False Positives. In the end, it wouldn't really matter if it is a false positive why it's false positive. The onyl time it would matter in my mind, is when you need to make adjustments to search for those incidents, hence the other group. Once you adjust the policy accordingly, you can then move it off to the False Positives status. Make sense?

I would suggest adding this to the ideas section of the forums, as I agree it would help in easing the tuning process. We've had the request before, but I don't think it's been voted for enough by customers. Unfortuantely the iterative process you first described is really the only way to work through them for right now.

The primary reason it matters if a false positive is marked as fixed in our environment is because we don't go live if our policies aren't below a certain false positive rate during the monitoring phase.  Being able to mark them as fixed lets us use the data we've already collected and still have valid false positive rates.

It is somewhat difficult task and not esaily possible , Please consider above suggestions.