On UEBA / UBA Use Cases

After much agonizing, we (Augusto and myself) have settled on the following list of UEBA / UBA use cases for our upcoming UEBA technology comparison. Here they are:

1. Compromised account detection: this is a “classic UBA” usage – study account authentication and usage information to conclude that the account is being used by a malicious party [or, at least, by a different party]; this is often powered by some logic to relate multiple accounts to the same person and/or logic to build sessions of user activity.
2. Compromised system/host/device detection: by detecting things like attacker lateral movement, C&C activity, access to bad domains [unknown ones, not just via TI!], various telling host and network anomalies, etc reach a conclusion that a system is under malicious control; this use case covers many data sources and a lot of fairly dissimilar methods of “sense-making”
3. Data exfiltration detection: notably, DLP has not fully solved this one (ha!), but has since become a popular UEBA data source; data theft (“exfil”, if you want to sound cool!) detection by trusted insiders and outsiders (as well as their malware) presents a common UEBA tool use case.
4. Insider access abuse: this is a fuzziest on the list, this focuses on detecting malicious and risky behavior by legitimate trusted insiders, and includes all forms of privileged access abuse and misuse, among other things; typically powered by user profiling, outlier detection and risk scoring of the results
5. Gaining additional insight about the environment: a broad use case where UEBA tools are used for gaining better situational awareness; this also includes improved alerts prioritization and support for triage and investigation activities (yes, if you have to ask, hunting too)
6. Custom use case: a good UEBA tool should be able to address a weird client-specific user behavior analytics scenario, ideally without coding and [much] data science knowledge on behalf of a client.

As a side note, to those of you who object to the above because “these are too high-level”…OK…sure, they are. So you can treat them as use case groups or use case types. Or, clusters, if you want to sound smart and “data-science-y”…

BTW, compare/contrast to top SIEM use cases (there are of course many more use cases for SIEM than the top ones mentioned).

Thoughts? Ideas? Additions? Complaints? Silly remarks about “but we have AI!!!”? 🙂

Related blog posts about security analytics:

• UEBA Clearly Defined, Again?
• Comparing UEBA Solutions (by Augusto)
• What Should Your UEBA Show: Indications or Conclusions?
• 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?