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 […].” (readmore if you have aGartner 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 doesnot 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 forfuture 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?
Category: analytics security ueba