What Should Your UEBA Show: Indications or Conclusions?

While starting to research UBA / UEBA and other analytics-related security tools, one interesting paradox has emerged. I’d call it “INSIGHT vs CERTAINTY paradox.”

Specifically:

1. Some UEBA users and prospects say “give me CERTAINTY” (some grumpily add: “I can get ‘false positives’ from my SIEM, should I want them”)
2. Other UEBA users say “give me INSIGHT about things I won’t know otherwise” (and some remind us: “if I want detection of basic threats, I can go to my SIEM”)

But aren’t those a tad contradictory? Can people be looking at UEBA to solve all their security monitoring problems, including some that seem to be a subject to “zero sum game”?

Furthermore, this led to an additional paradox: as some users from camp #1 above push UEBA vendors to deliver “certainty now”, the vendors are tempted to just fall back to rules (and away from analytics). After all, if a vendor engineer can quickly cook up a rule that “shows something”, the POC will go better… Rules are indeed an easier way to certainty, being very black and while (matches the rule vs does not match the rule).

However, the chance that the rules will catch “unknown unknowns” is of course ZERO. Frankly, the chance of catching those pesky “known unknowns” is probably very low too. At the same time, rules are often a clean way to product a signal with high certainty, and work well for “known knowns” [that can still hurt you, of course – see ransomware]

In other cases, some people at the organization (e.g. SOC Level 1 analysts) may prefer a signal with high certainty, while others will vote for deeper insight at the cost of lower certainty (e.g. threat hunters, if you have any).

My conclusion? If you want real UEBA | UBA and real analytics, you will have to learn to live with [some] uncertainty. Look for vendors that use analytics to make their own analytics-produced alerts, scores and signals more useful (such as for giving better historical context or by using 2nd stage analytics), who apply data science to the problems they face with signal quality – and treat carefully around those that use hand-written rules as a crutch all the time…

Related blog posts about security analytics:

• UEBA Shines Where SIEM Whines?
• The Coming UBA / UEBA – SIEM War!
• Next Research: Back to Security Analytics and UBA/UEBA
• Sad Hilarity of Predictive Analytics in Security?
• Security Analytics Webinar Questions – Answered
• On Unknown Operational Effectiveness of Security Analytics Tooling
• My “Demystifying Security Analytics: Sources, Methods and Use Cases” Paper Publishes
• Now That We Have All That Data What Do We Do, Revisited
• Killed by AI Much? A Rise of Non-deterministic Security!
• Those Pesky Users: How To Catch Bad Usage of Good Accounts
• Security Analytics Lessons Learned — and Ignored!
• Security Analytics: Projects vs Boxes (Build vs Buy)?
• Do You Want “Security Analytics” Or Do You Just Hate Your SIEM?
• Security Analytics – Finally Emerging For Real?
• Why No Security Analytics Market? <- important read for VCs and investors!
• More On Big Data Security Analytics Readiness
• 9 Reasons Why Building A Big Data Security Analytics Tool Is Like Building a Flying Car
• “Big Analytics” for Security: A Harbinger or An Outlier?