Ok, so after yet another request to “define UBA | UEBA clearly”, this post was born. First, Gartner “Market Guide for User and Entity Behavior Analytics” (not the research we are planning, BTW) just went up and its authors do spent time clarifying UEBA characteristics. To quote,
“User and entity behavior analytics offers profiling and anomaly detection based on a range of analytics approaches, usually using a combination of basic analytics methods (e.g., rules that leverage signatures, pattern matching and simple statistics) and advanced analytics (e.g., supervised and unsupervised machine learning). Vendors use packaged analytics to evaluate the activity of users and other entities (hosts, applications, network traffic and data repositories) to discover potential incidents […].” (read more if you have a Gartner subscription; there are 5 characteristics of UEBA vendors, for example)
This of course makes total sense, but let me try to make it a bit more crispy, like so:
- U – UEBA is USER-centric. Not “user-related”, “user-assisted”, but user-centric. It is about analyzing user [and/or user account, since occasionally user account is not in the hands of its user] activities as its primary mission and purpose, not about security analytics in general. So, “U” is a MUST for UEBA.
- E – However, UEBA is not user-exclusive. UEBA technologies analyze other things in addition to users (hosts, devices, etc). So, UEBA is not EBA, it is essentially (U+E)BA. Going beyond “U” to other “E” is not a must for UEBA.
- B – the “B” in UEBA points at the focus on user behaviors and activities, not their roles and privileges and other attributes and static parameters. Of course, UEBA tech needs those parameters, but its primary mission is to find interesting and malicious behaviors.
- A – finally, advanced analytics rather than simple rule-based matching is another part of “UEBA DNA.” This does not have to be ML, but it better be more than solely hard-coded rules, thresholds and averages. Analytics is definitely a MUST for UEBA.
There you have it… better now? Still got questions?
BTW, this definition sidesteps “UEBA feature vs UEBA product” question, and this is left for future blogging…
Related blog posts about security analytics:
- 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?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.