The tuning of DLP policy is a mandatory task that will better protect your information assets and simplify the activity of those to assess DLP incidents.
Unfortunately there are no magic rules or tools to perform policy tuning. Each DLP expert has his own based on CSV or XML export to help tuning DLP policies and they need to add some courage, cleverness and imagination.
However, there are a number of guidelines that can help you cleaning your cluster of DLP incidents:
- Analyze false positives as you analyzed documents and information to protect in order to find meaningful patterns. Pattern recognition for these false positive incidents could be done by asking yourself the following question:
- Does this incident are raised by the same user?
- Does this incident are sent to same destination?
- Does this incident are triggering by same keyword?
- Does this incident are triggering just above rules threshold?
- Does this incident are triggering by same EDM fields combination?
- Does this document triggering my policies contain something specific I will never find in documents I want to protect?
- …..(This is where imagination comes into play)
- In SYMANTEC DLP, a message can raise more than one incident. According to the incident assessment process, it can double the workload for DLP stakeholders. It is therefore necessary to analyze messages that have raised more than one incident. If it always happens for the same set of policies it means that there may be an overlap between them. So you may check following:
- Does this double incident were triggered by same source document in my IDM
- Does this incident were triggered by same keywords?
- Does this incident were triggered by different components?
- …..(This is where imagination comes into play)
These analyzes should allow you to greatly reduce number of unexpected incident, the last will be the most recalcitrant (and most interesting) and you must also accept that some will not be removed automatically. In order to perform them, it is important to provide access to these incidents to people in charge of your DLP policies management especially few weeks after policy creation/update.
Then you have to translate analysis results into your DLP policies:
- By adding exclusions (some rule types may not be available for exception definition)
- By deleting some criteria in your detection rules (Ex: In your list of 200 keywords, the little disruptive generating all these false positives is it really fundamental?)
- By using another rule type than the one firstly chosen (keyword or regular expression? Regular expression or data identifier? Pre-defined file type or custom file type? …)
- By transforming a simple rule into a compound rule
- By changing the content of your IDM
- By adding a field from your EDM source in your search criteria
- ...... (This is where imagination comes into play)
Lot of these tasks could be performed before going live if you have a dedicated environment to perform some testing and some tools to simulate network flows (mail, web, …) or workstation activities (copy to usb, printing, application…). This environment may also help you validating that your detection rules are really able to detect what you want to protect.