Index / Detection and tuning

The False Positive Problem

kind
Procedure
domain
Tuning
stage
Detection and tuning
read
3 min
assumes
No prior programme in place

Every DLP deployment drowns at first. What causes it, how to reduce it, and why the usual response makes it worse.

The characteristic experience of a new deployment: several thousand alerts in the first week, of which perhaps five are interesting.

The usual response is to raise thresholds until the volume is tolerable, which reduces noise and detection together. There are better approaches.

Where the noise comes from

Generic patterns. A policy matching anything shaped like a national identifier will fire on test data, sample records, documentation, and numbers that happen to have the right form. Pattern matching without context is the largest single source.

Approved workflows. Legitimate business processes that look identical to violations. Every organisation has several and almost none has enumerated them.

Internal movement counted as egress. Data moving between sanctioned systems, flagged because the policy did not distinguish internal from external destinations.

Automated activity. Backup agents, sync clients, integration accounts, scanners. High volume, entirely legitimate, and frequently indistinguishable from bulk exfiltration to a naive rule.

One person, many alerts. A single action can generate dozens of events. Alert counts overstate reality unless events are correlated into incidents.

Reducing it properly

Add context to content. A pattern match plus destination plus user role plus volume is far more precise than a pattern match alone. Most products support this and most deployments do not use it, because the default policies do not.

Enumerate approved workflows and exclude them explicitly. With documentation and a review date, so exclusions do not become permanent holes nobody remembers.

Exclude service accounts and automated processes, deliberately, with a separate detection watching for anomalies in those accounts. They are a real exfiltration route and they should not be in the same queue as human activity.

Correlate events into incidents. Twenty files in one session is one incident, not twenty alerts.

Use your own data. Fingerprinting actual sensitive documents, or matching against the real customer database, is dramatically more precise than a generic pattern. It requires setup, which is why it gets skipped, and it is the single largest precision improvement available.

Tune per policy, not globally. Global thresholds hide the fact that one badly designed rule is producing most of the noise.

What not to do

Do not raise thresholds until it is quiet. This is the common response and it produces a programme that sees only the most extreme activity, which is not where most risk lives.

Do not close alerts in bulk without review. The habit forms quickly and it is the mechanism by which real incidents get missed.

Do not measure success by low alert volume. A programme with no alerts is either perfectly tuned or broken, and the metric cannot distinguish them.

The cost of false positives is not just time

Analyst attention degrades. A queue that is ninety-nine percent noise trains people to dismiss quickly, and the dismissal habit does not switch off for the one that matters.

The business loses confidence. Every false accusation, even one gently handled, spends credibility. Two or three and cooperation stops.

Employees lose trust. Someone questioned about legitimate work concludes the monitoring is arbitrary. That conclusion spreads faster than any awareness programme.

A workable target

A volume the assigned reviewer can genuinely examine, every day, with attention.

For most organisations that is single digits to low tens per day. If you are above it, the answer is more precision, not more analysts โ€” because a second analyst reviewing an imprecise queue produces twice the dismissals, not twice the detection.