False Positives and Machine Learning, Part 2
In Part 1 I described the false positive problem and the usual ways of measuring it. This part covers how threat detection has changed and what I think we should measure instead.
How detection has changed
Earlier approaches:
- static rulesets (ACLs, blocklists),
- statistical anomaly detection,
- basic ML analysis.
What we use now:
- ML-based behavioral analytics (UEBA),
- automated parameter tuning,
- business metrics as part of the loop.
The old choice was between statistical methods, which are powerful but complex to run, and static rulesets, which are simple but limited. Automated tuning narrows that gap.
Measure business outcomes, not just accuracy
The false positive rate, FP / (FP + TN), and accuracy, (TP + TN) / (FP + TP + FN + TN), don't tell you what a wrong decision costs the business. So I use business outcomes as a security metric:
- Track conversion rates against security decisions. If blocking goes up and conversions go down, something is wrong.
- Use UEBA as a feedback loop.
- Adjust the algorithms based on business impact.
Looking at whole sessions, not single requests, helps a lot here. A sequence of requests shows how a real customer behaves and makes it easier to separate customers from bots.
What a decision should take into account
Instead of a plain allow/block, a decision should consider:
- the user's history,
- the business value of the transaction,
- the current threat landscape,
- how much risk the organization is willing to accept.
Policies can then be adjusted automatically as business conditions change.
My main conclusion from this work: security has to support the business, not only stop threats. False positives won't disappear, but when you measure them against business outcomes, they become predictable and manageable.